System and method for accessing vehicle communication applications requiring vehicle identification without re-entering vehicle identification

ABSTRACT

Methods and apparatus are provided for repairing vehicles. A computing device having first and second software executables can determine vehicle identification information (VII) that identifies a vehicle. The computing device can store first and second vehicle identifiers that are based on the VII and are respectively associated with the first and second software executables, where the first vehicle identifier differs from the second vehicle identifier. The computing device can be used to repair the vehicle by at least: receiving a request to activate the first software executable, and activating the first software executable at least by providing the stored first vehicle identifier to the first software executable.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation application of U.S. patentapplication Ser. No. 16/409,705, entitled “System and Method forAccessing Vehicle Communication Applications Requiring VehicleIdentification without Re-Entering Vehicle Identification,” filed May10, 2019. U.S. patent application Ser. No. 16/409,705 is a continuationapplication of U.S. patent application Ser. No. 15/674,436, entitled“System and Method for Accessing Vehicle Communication ApplicationsRequiring Vehicle Identification without Re-Entering VehicleIdentification,” filed Aug. 10, 2017. U.S. patent application Ser. No.15/674,436 issued on Jun. 25, 2019 as U.S. Pat. No. 10,331,687. U.S.patent application Ser. No. 16/409,705 and U.S. patent application Ser.No. 15/674,436 are incorporated herein by reference.

BACKGROUND

Unless otherwise indicated herein, the materials described in thissection are not prior art to the claims in this application and are notadmitted to be prior art by inclusion in this section.

Vehicles, such as automobiles, light-duty trucks, and heavy-duty trucks,play an important role in the lives of many people. To keep vehiclesoperational, some of those people rely on vehicle technicians todiagnose and repair their vehicle.

Vehicle technicians use a variety of tools in order to diagnose and/orrepair vehicles. Those tools may include common hand tools, such aswrenches, hammers, pliers, screwdrivers and socket sets, or morevehicle-specific tools, such as cylinder hones, piston-ring compressors,and vehicle brake tools. The tools used by vehicle technicians may alsoinclude electronic tools such as a vehicle scan tool or a digitalvoltage-ohm meter (DVOM), for use in diagnosing and/or repairing avehicle.

The vehicle scan tool and/or DVOM can be linked via wired and/orwireless link(s) to other devices, perhaps to communicate data about thevehicle. The vehicle scan tool and/or DVOM can provide a significantamount of data to aid diagnosis and repair of the vehicle. This data isprovided using a number of different functions of the vehicle scan tooland/or DVOM including functions for scanning for diagnostic data andfunctions performing tests on the vehicle.

SUMMARY

In one aspect, a method is provided. A computing device determinesvehicle identification information (VII) that identifies a vehicle. Thecomputing device includes a first software executable and a secondsoftware executable. The computing device stores a first vehicleidentifier associated with the first software executable and a secondvehicle identifier associated with the second software executable basedon the VII. The first vehicle identifier differs from the second vehicleidentifier. The computing device is used to repair the vehicle by atleast: receiving a request to activate the first software executable andactivating the first software executable at least by providing thestored first vehicle identifier to the first software executable.

In another aspect, a computing device is provided. The computing deviceincludes a processor and a computer readable medium. The computerreadable medium stores at least a first software executable, a secondsoftware executable, and executable instructions. The executableinstructions, when executed by the processor, cause the computing deviceto perform functions. The functions include: determining VII thatidentifies a vehicle; storing, at the computer readable medium, a firstvehicle identifier associated with the first software executable and asecond vehicle identifier associated with the second software executablebased on the VII, where the first vehicle identifier differs from thesecond vehicle identifier; and repairing the vehicle using the computingdevice by at least: receiving a request to activate the first softwareexecutable, and activating the first software executable at least byproviding the stored first vehicle identifier to the first softwareexecutable.

In another aspect, a non-transitory computer readable medium isprovided. The computer readable medium is configured to store at leastexecutable instructions. The executable instructions, when executed by aprocessor of a computing device, cause the computing device to performfunctions. The functions include: determining VII that identifies avehicle; storing, at the computing device, a first vehicle identifierassociated with the first software executable and a second vehicleidentifier associated with the second software executable based on theVII, where the first vehicle identifier differs from the second vehicleidentifier; and repairing the vehicle by at least: receiving a requestto activate the first software executable, and activating the firstsoftware executable at least by providing the stored first vehicleidentifier to the first software executable.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows a scenario using a prior art automotive diagnosis tool.

FIG. 2 is a flowchart of a method, in accordance with an embodiment.

FIG. 3 depicts a vehicle identifier file and repair data, in accordancewith an embodiment.

FIG. 4 shows a communication flow during repair of a vehicle, inaccordance with an embodiment.

FIG. 5 shows a communication flow during repair of a vehicle, inaccordance with an embodiment.

FIG. 6 shows a communication flow during repair of a vehicle, inaccordance with an embodiment.

FIG. 7 shows a communication flow during repair of a vehicle, inaccordance with an embodiment.

FIGS. 8, 9, 10A, 10B, 10C, 11, 12, 13A, 13B, 13C, 13D, 13E, 14A, 14B,14C, and 14D show two related scenarios where a computing device is usedto repair a vehicle, in accordance with an embodiment.

FIG. 15 is a block diagram of an example computing network, inaccordance with an embodiment.

FIG. 16A is a block diagram of an example computing device, inaccordance with an embodiment.

FIG. 16B depicts an example network of computing centers, in accordancewith an embodiment.

FIG. 17 is a flow chart of an example method, in accordance with anembodiment.

DETAILED DESCRIPTION

Accessing Vehicle Communication Applications without Re-Entering VehicleIdentification

A vehicle scan tool is frequently used in diagnosing and repairingfaults in vehicles under repair. The vehicle scan tool can include acomputing device configured to perform multiple repair-related functionsusing multiple software executables. Some of the software executablescan perform vehicle-specific functions, and so can require a vehicleidentifier as an initial input. A typical technique to provide thevehicle identifiers to the software executables of the vehicle scan toolis to have a technician operating the vehicle scan tool provide avehicle identifier for a software executable each time the softwareexecutable is run.

As used herein, the term software executable includes one or morecomputer-readable instructions encoded in a format that can be executedby one or more computer processors of a computing device, such as acomputing device acting as a vehicle scan tool. The software executableand/or other data can be resident on the device; that is, the softwareexecutable and/or other data can be stored in memory of the device thatis accessible to the one or more computer processors of the computingdevice. The software executable may rely on other software, such as aninterpreter, to be executed and thereby perform one or more tasks; i.e.,a software executable can include instructions that are executed by acomputer processor by way of executing an interpreter operating oninstructions in the software executable as input. In some examples, asoftware executable can rely upon special hardware, such as testingcomponents or communications interface hardware, to perform some or allof its tasks. As used herein, a software module can include part or allof one or more software executables.

FIG. 1 shows scenario 100 using a prior art automotive diagnosis tool.Scenario 100 starts with a technician powering up the prior artautomotive diagnosis tool, and the prior art automotive diagnosis toolsubsequently presenting screen 110 for the technician to provide aninput to select one of three software executables while repairing avehicle V0. Screen 110 indicates that the technician can select “1” touse a “Vehicle Scan” executable, “2” to use a “Vehicle Test” executable,“3” to use a “Repair Info” executable, or “X” to exit and power down theprior art automotive diagnosis tool.

Scenario 100 continues with the technician entering a “1” to use theVehicle Scan executable, and the prior art automotive diagnosis toolsubsequently providing screen 120 to the technician to enter data for avehicle identifier of vehicle V0 for the Vehicle Scan executable, wherethis vehicle identifier is based on data input by the technician thatincludes a “Year”, “Make”, “Model”, and “# of Cylinders”. After enteringthis data, the prior art automotive diagnosis tool activates the VehicleScan executable as shown by screen 130 of FIG. 1.

Scenario 100 proceeds with the technician completing use of the VehicleScan executable during the repair of vehicle V0 and the prior artautomotive diagnosis tool presenting screen 140, which is the same asscreen 110, for the technician to either select an executable or topower down the prior art automotive diagnosis tool. Scenario 100proceeds with the technician entering a “3” to use the Repair Infoexecutable. In response to the “3” being entered at screen 140, theprior art automotive diagnosis tool presents screen 150 for thetechnician to enter data for a vehicle identifier of vehicle V0 for theRepair Info executable, where this vehicle identifier is based on datainput by the technician that includes a “Year”, “Make”, “Model”, and“Type of Fuel”. After entering this data, the prior art automotivediagnosis tool activates the Repair Info executable as shown by screen160 of FIG. 1. After screen 160 is presented, scenario 100 is completed.

Scenario 100 illustrates that vehicle identifiers can vary betweensoftware executables, but many (if not all) vehicle identifiers arebased on similar data. For example, scenario 100 illustrates that thevehicle identifier of the prior art Vehicle Scan Module is based on theyear, make (manufacturer's name), model, and number of cylinders forvehicle V0, and the vehicle identifier of the prior art Repair Infoexecutable is based on the year, make, model, and type of fuel forvehicle V0. However, each time a technician activated a softwareexecutable of the prior art automotive diagnosis tool in scenario 100,the technician had to enter vehicle-identifier-related data. Further, itis typical that when the same software executable is activated multipletimes during a repair session of a vehicle, the samevehicle-identifier-related data has to be input by the technician eachtime the software executable executed. Thus, the technician may have toprovide the same or similar vehicle-identifier-related data to the priorart automotive diagnosis tool multiple times during a repair session.

Herein are described techniques to provide common vehicle identificationfor software executables of a vehicle scan tool, at least to save time,reduce data entry, and ease usage of the vehicle scan tool. The commonvehicle identification techniques can obtain vehicle-identifier-relateddata once and then provide specific vehicle identifiers to the softwareexecutables of the vehicle scan tool as needed during a repair sessionfor repairing a vehicle.

Common vehicle identification can involve obtaining vehicleidentification information (VII), obtaining specific vehicle identifiersfor software executables of a vehicle scan tool, where each of thespecific vehicle identifiers that are based on the VII, and store thespecific vehicle identifiers. Then, after a technician requestsactivation of a particular software executable of a vehicle scan tool(e.g., during a repair session), the vehicle scan tool can retrieve thespecific vehicle identifier for the particular software executable andprovide the retrieved specific vehicle identifier as part of activatingthe particular software executable without any additional informationfrom the technician.

In some examples, the VII can include a vehicle identification number(VIN) of a vehicle under repair. Then, the VIN can be parsed to obtainmuch of the data in the specific vehicle identifiers; e.g., make, model,and year of manufacture. For additional data that may not directlyprovided by parsing the VIN, such as a type of fuel, data from the VINcan be used to obtain the additional data; e.g., by using data from theVIN to query one or more databases, and obtaining the additional datafrom query responses from the database. In these cases, the VII caninclude data obtained from the VIN and the additional data.

Then, the VII can be used to generate the vehicle identifiers for thesoftware executables of the vehicle scan tool. In some cases, part orall of the VII can be formatted to generate a particular vehicleidentifier; e.g., one vehicle identifier can use a 2-digit number as ayear of manufacture, while another vehicle identifier can use a 4-digitnumber as the year of manufacture; a vehicle identifier can betranslated to a specific language or dialect (English, German, Spanish,etc.). For example, a vehicle identifier that includes a type of fuelcan use the word “gas” for US English, “petrol” for UK English,“benzene” for German, and “essence” for French.

After the vehicle identifiers for the software executables of thevehicle scan tool have been identified, the vehicle scan tool can beused during a repair session to repair the vehicle under repair. Forexample, the vehicle scan tool can be used to request one or moreDiagnostic Trouble Codes (DTCs, which are also called fault codes) fromthe vehicle. The vehicle can provide the requested DTC(s), which canindicate faults perhaps observed by one or more sensors and/or othercomponents (e.g., control units) of the vehicle, to the vehicle scantool. The vehicle scan tool can display one or more selectors for eachof the DTC(s). A technician repairing the vehicle can review the DTCsand can select a first selector associated with a first DTC to beaddressed in repairing the vehicle. Upon selection of the first selectorassociated with the first DTC, the vehicle scan tool can send a requestfor enhanced repair data, such as testing and parameter-related data,associated with the DTC to a server computing device (or server, forshort). The server can access a global repair data database storingrepair data obtained for a plurality of vehicles to obtain the enhancedrepair data based on the DTC, the VII and/or vehicle identifiers, andperhaps additional data. After obtaining the enhanced repair data fromthe global repair data database (and perhaps other sources), the serversends the enhanced repair data to the vehicle scan tool. If the vehiclescan tool cannot communicate with the server, the vehicle scan tool useslocally-stored or “default” data in lieu of the enhanced repair data.

After receiving the selection of the first selector and any availableenhanced repair data, the vehicle scan tool can generate and present arepair page that includes one or more displays and controls forproviding information and/or carrying out tests in order to repair thevehicle; e.g., the repair page can be presented using one or more outputdisplay devices. The repair page can indicate whether or not the vehiclescan tool is connected to a server and the displays and controls of therepair page can be based on the enhanced repair data (if available) ordefault data (if enhanced repair data is unavailable). The controls ofthe repair page allow the technician using the vehicle scan tool torequest activation of resident software executables.

Examples of the software executables resident on the vehicle scan toolinclude, but are not limited to, an executable for scanning a vehiclefor information, an executable for performing component tests on avehicle, an executable for performing functional tests on a vehicle, andan executable for performing vehicle information retrieval. Theexecutable for scanning a vehicle for information can cause residentsoftware to communicate with an Engine Control Unit (ECU) and/or othercomponents of the vehicle to obtain DTCs, parameter values associatedwith parameter identifiers (PIDs), and perhaps other information fromthe vehicle (e.g., a VIN) according to a vehicle communication protocol,such as the On-board Diagnostics II (OBD-II) protocol.

The executables for performing component tests and performing functionaltests can respectively perform tests on a per-component and on aper-vehicle-function basis. These executables can use digital electronicmeasuring components, such as digital oscilloscopes, ammeters,voltmeters, ohmmeters, etc., resident on the vehicle scan tool toperform the respective component and functional tests. These componentand functional tests can be tailored on a per-test basis to provideinformation to the technician about how to execute the test and/or howto interpret test results. The executable for performing vehicleinformation retrieval can provide repair tips, Original EquipmentManufacturer (OEM) repair information, technical service bulletins(TSBs); and/or other information related to the vehicle. The executablefor performing vehicle information retrieval can present one or moretitles (or other information) about respective vehicle information (suchas a TSB title)—then, subsequent selection of a particular title causesthe vehicle scan tool to send a request for the respective vehicleinformation associated with the title to the server. In response, theserver sends the respective vehicle information associated with thetitle to the vehicle scan tool, and the vehicle scan tool can displaythe respective vehicle information associated with the title. In otherexamples, more, fewer, and/or different software executables can beresident on the vehicle scan tool and/or accessible via the controls ofthe repair page.

Selection of a control that requests activation of a software executablecan cause the vehicle scan tool to retrieve a stored vehicle identifierfor the activated software executable, and to provide the stored vehicleidentifier to the activated software executable upon activation—that is,the technician need not provide data related to the vehicle identifierto activate the software executable; rather the vehicle scan tool canretrieve the stored vehicle identifier rather than requesting additionaldata entry by the technician as indicated in scenario 100. This savestechnician time and effort, and also reduces human error while repairingvehicles.

By obtaining VII once and using the VII to obtain one or more vehicleidentifiers, the amount of vehicle-identifier specific data provided bythe technician to activate software executables of the vehicle scan toolcan be reduced or even eliminated. For example, in some examples, thevehicle scan tool can be connected to a vehicle under repair, obtain theVIN from the vehicle under repair, use the VIN to obtain VII, generatevehicle identifiers from the VII, and save the vehicle identifiers forlater use—all without requesting vehicle-identifier specific input fromthe technician or from the vehicle more than once. Reducing the amountof data required from the technician saves time. Also, the data providedis not subject to human error, further saving time in correcting dataentry errors. Additionally, not having to type in as much data,particularly redundant data, into a vehicle scan tool during a repairsession makes the vehicle scan tool easier to use.

Example Common Vehicle Identification Systems and Techniques

FIG. 2 is a flowchart of method 200, in accordance with an embodiment.Part or all of method 200 can be performed by a computing device actingas and/or embodied as a vehicle scan tool to repair a vehicle V1, suchas computing device 1600 discussed below at least in the context of FIG.16.

Method 200 begins at block 210, where the vehicle scan tool candetermine one or more software executables SE1, SE2 . . . SEn, n>0,resident on the vehicle scan tool. For example, some or all of softwareexecutables SE1, SE2 . . . SEn can be used in repairing vehicle V1. Insome examples, such as examples where method 200 is executed whilevehicle identifiers are obtained as needed, the procedures of block 210can be omitted and/or deferred during execution of method 200.

At block 220, the vehicle scan tool can obtain VII from vehicle V1and/or a user of the vehicle scan tool; e.g., a technician repairingvehicle V1. As one example, the vehicle scan tool can be connected to anOBD-II data port and/or another data port of vehicle V1 and then queryvehicle V1 for data related to the VII via the OBD-II and/or other dataport(s); e.g., the VIN of vehicle V1. As another example, the vehiclescan tool can prompt the user to provide the VII. In other examples, thevehicle scan tool can obtain some or all of the VII from vehicle V1 andthen ask the user to verify the correctness of the obtained VII. Otherexamples of obtaining VII from vehicle V1 and/or a user of the vehiclescan tool are possible as well.

At block 230, the vehicle scan tool can determine whether the vehiclescan tool is connected to a server. If the vehicle scan tool isconnected to the server, the vehicle scan tool can proceed to block 232.Otherwise, the vehicle scan tool is not connected to the server and thevehicle scan tool can proceed to block 242.

At block 232, the vehicle scan tool can generate a query Q1 for nvehicle identifiers VID1, VID2 . . . VIDn for the respective softwareexecutables SE1, SE2 . . . SEn. The query Q1 can include some or all ofthe VII and/or data derived from the VII obtained at block 210.

At block 234, the vehicle scan tool can send query Q1 to the server torequest the vehicle identifiers VID1, VID2 . . . VIDn. In response, theserver can send a query response QR1 to the vehicle scan tool thatincludes the requested vehicle identifiers VID1, VID2 . . . VIDn. Uponcompletion of block 234, the vehicle scan tool can proceed to block 250.

At block 242, the vehicle scan tool can generate a query Q2 for nvehicle identifiers VID1, VID2 . . . VIDn for the respective softwareexecutables SE1, SE2 . . . SEn. The query Q2 can include some or all ofthe VII and/or data derived from the VII obtained at block 210.

At block 244, the vehicle scan tool can send query Q2 to a localidentifier database to request the vehicle identifiers VID1, VID2 . . .VIDn, where the local identifier database is stored on the vehicle scantool. In response, the local identifier database can send a queryresponse QR2 to the vehicle scan tool that includes the requestedvehicle identifiers VID1, VID2 . . . VIDn.

In some examples, query Q1 is the same as query Q2. In other examples, aquery is formatted differently or otherwise differs depending on whethera destination of the query is the server or is the local database—inthese examples, Q1 differs from Q2.

At block 250, the vehicle scan tool can store the vehicle identifiersVID1, VID2 . . . VIDn obtained via query response QR1 or query responseQR2. The vehicle identifiers VID1, VID2 VIDn can be stored innon-volatile memory, such as in a vehicle identifier file stored insecondary or persistent long term storage, and/or in volatile memory,such as in repair data stored in one or more of: registers, processorcaches, and/or random access memories. Vehicle identifier files andrepair data are discussed below in the context of at least FIG. 3.

As shown at block 260 of FIG. 2, the vehicle scan tool can receive arequest to activate a software executable SEi, where 1≤i≤n.

At block 262, the vehicle scan tool can retrieve a vehicle identifierVIDi that is associated with software executable SEi from storage, wherethe vehicle identifier VIDi was stored at block 250.

At block 264, the vehicle scan tool can activate software executable SEiby starting to execute software executable SEi and by providing vehicleidentifier VIDi during activation. For example, the vehicle scan toolcan pass in vehicle identifier VIDi as a parameter to softwareexecutable SEi as part of starting to execute software executable SEi.As another example, software executable SEi can request that the vehiclescan tool provide software executable SEi and the vehicle scan tool canresponsively provide vehicle identifier VIDi. Other techniques forproviding vehicle identifier VIDi during activation of softwareexecutable SEi are possible as well.

At block 270, the vehicle scan tool can be used to repair vehicle V1.FIGS. 4-14C below show example scenarios where a computing device usedas a vehicle scan tool to repair vehicles.

As shown at block 280 of FIG. 2, the vehicle scan tool can determinewhether to activate another software executable while repairing vehicleV1. If the vehicle scan tool determines that another software executableis to be activated (e.g., a repair session to repair vehicle V1continues with the user requesting activation of a software executable),the vehicle scan tool can proceed to block 260. If the vehicle scan tooldetermines that another software executable is not to be activated(e.g., the repair session for vehicle V1 has ended and the user hasrequested power down of the vehicle scan tool), method 200 can becompleted.

FIG. 3 depicts vehicle identifier (VID) file 310 and enhanced repairdata 330, in accordance with an embodiment. Vehicle identifier file 310can have n entries for n software executables, n>0, where each entry caninclude at least two fields of data: a field of data for softwareexecutable (SE) 320 and a field of data for a VID 322. In the exampleshown in FIG. 3, vehicle identifier file 310 includes data for threesoftware executables as shown by field 320: software executables “SE1”,“SE2”, and “SE3”. Field 322 includes the corresponding, respectivevehicle identifiers for the software executables “2012 Maker1 PickupModel1 4.6 L Gas”, “2012 Maker1 Pickup Model1 4.6 L”, and “2012 Maker1Model 1 (2WD) 4.6 L V8 SOHC SEFI”. For example, the vehicle identifierfor software executable SE3 includes data about a vehicle including: ayear of manufacture “2012”, a make “Maker1”, a model “Pickup Model1”, anumber of powered wheels “2WD” indicating two-wheel drive, and an engineof the vehicle “4.6 L V8 SOHC SEFI” which indicates that the vehicle'sengine is a 4.6 liter V8 engine having a single over-head cam (SOHC) andsequential electronic fuel injection (SEFI). As other examples, thevehicle identifier for software executable SE1 includes the year, make,and model data used for the vehicle identifier of software executableSE3, some of the engine-related data “4.6 L”, and information about afuel utilized by the vehicle “Gas” and the vehicle identifier forsoftware executable SE2 is a subset of the data for either softwareexecutable SE1 or software executable SE3.

More generally, a vehicle identifier can include some or all of at leastthe following information about a vehicle: a make/manufacturer name ofthe vehicle, year of manufacture of the vehicle, model information forof the vehicle, information about components of the vehicle, informationrelated to a VIN, serial number, and/or other identifying number(s)associated with the vehicle, information about location of manufactureor use of the vehicle, and other information related to the vehicle(e.g., a type of fuel used by the vehicle, a number of powered wheels).Many other examples of vehicle identifiers are possible as well.

Enhanced repair data 330 can include data about vehicle identifiers andother data related to repairing a vehicle. FIG. 3 shows that enhancedrepair data 330 can include at least two portions: a first portion withvehicle identifier data 340 and a second portion with diagnostic data360. Vehicle identifier data 340 can have entries including at least twofields: a software executable field 350 and a vehicle identifier field352. In some examples, each entry in vehicle identifier data 340 can bethe same as the entries of vehicle identifier file 310 discussed above.In particular, software executable field 350 in vehicle identifier data340 can be the same as software executable field 320 of vehicleidentifier file 310 and vehicle identifier 352 in vehicle identifierdata 340 can be the same as vehicle identifier 322 of vehicle identifierfile 310.

Diagnostic data 360 can include vehicle data 370 and intelligent repairdata 380. Vehicle data 370 can include data obtained from a vehicle;e.g., a vehicle under repair. In particular, vehicle data 370 caninclude DTCs, PIDs, and related fault code data and/or parameter data.As shown in FIG. 3, the fault code data can include data about a“Current Fault Code” and “Other Fault Codes”. The current fault code canbe a fault code that was most recently generated by a vehicle underservice and the other fault codes can be fault codes that are older thanand perhaps related to the current fault code.

The PIDs and related parameter data can include data on a per-PID basis.The data on a per-PID basis can include a parameter identifier and datafor the parameter identified by the parameter identifier. In someexamples, some or all of vehicle data can be or include data obtainedvia an OBD-II data port of a vehicle under service, where the data caninclude OBD-II DTCs, OBD-II PIDs, and data for the parameters identifiedby the PIDs.

Data in diagnostic data 360 can be used to update PID lists and/orsuggest tests for execution. A PID list can specify a group or list ofPIDs to be observed (scanned) by the vehicle scan tool. For example,PIDs and related parameter data of diagnostic data 360 can identifyparameters that can be selected for a new PID list. If a number of PIDsand/or PIDs provided in diagnostic data 360 differs from a number ofPIDs in one or more particular PID lists (e.g., a PID list that has someof the PIDs provided in diagnostic data 360), then a server (or multipleservers) in communication with the vehicle scan tool can examine thenumber of PIDs and/or PIDs in diagnostic data 360 for possibleinclusion, exclusion, and/or updating of the one or more particular PIDlists.

Also, related parameter data provided in diagnostic data 360 can be usedby the server for PID list generation. For example, the server canreceive related parameter data for one or more PIDs that is/are outsideof a range of expected values during number of repair sessions involvingvehicles having partially or completely the same Year/Make/Model/Engine(YMME) values. Then, the server can reorganize one or more PID lists forvehicles having partially or completely the same YMME values tohighlight the PID(s) that have been observed to be more likely tooutside of the range of expected values; e.g., put likely out-of-rangePIDs at the top, bottom, or other well-defined region of the PID list(such as in a portion of the PID list headed with a “Likely Out of RangePIDs” header). After updating the PID list, the server can provide theupdated PID list(s) to the vehicle scan tool either via enhanced repairdata 330 and/or as one or more updates to one or more default PID listsstored on the vehicle scan tool. Other updates to PID lists and/orsuggested tests based on data in diagnostic data 360 are possible aswell.

Intelligent repair data 380 can include one or more PID list identifiersand/or one or more identified tests, as indicated in FIG. 3. A PID listidentifier can be used to specify or identify a PID list. Then, a PIDlist identifier can be provided to the vehicle scan tool as part of aninstruction to obtain data about the parameters referred to in a PIDlist that is identified by the PID list identifier. For example, a PIDlist identifier can identify parameters used to diagnose and/or repairparticular faults in the vehicle, such as faults identified by faultcodes in vehicle data 370. Some or all of the identified PID lists canbe previously stored on the vehicle scan tool; thus, the PID listidentifier makes use of an already-stored (and available) PID list ofthe vehicle scan tool.

The one or more identified tests can include tests to obtain data,verify functionality, and/or get other information about the vehicle.The identified test(s) can include one or more component tests and/orone or more functional tests. A component test is a test related to oneor more specific parts or components of the vehicle, and a functionaltest is a test related to one or more specific features or functions ofthe vehicle. The vehicle scan tool can then be configured to execute theone or more identified tests.

The server can enhance an existing default set of PID lists by providinga different ordering and/or different set of lists to the PID list basedon information about previous repairs of other (e.g., similar) vehicles.In some examples, an identified PID list can be provided by the server.Thus, the PID list identifiers can be enhanced by the server. Similarly,the identified tests can be tests identified by the server based oninformation about previous repairs of other (e.g., similar) vehicles.

In operation, the vehicle scan tool can determine an initial instance ofenhanced repair data 330 by obtaining data for VID data 340, such asvalues for software executables 350 and VII, such as VII obtained from auser of the vehicle scan tool and/or VII obtained from a vehicle underrepair. Then, after determining the initial instance of enhanced repairdata 330, the vehicle scan tool can send the initial instance ofenhanced repair data 330 to the server. The server can then update theinitial instance of enhanced repair data 330 by providing VID(s) 352 inan updated instance of enhanced repair data 330 that are related to thevalues for software executables and/or VII provided in the initialinstance. The server can then send the updated instance of enhancedrepair data 330 to the vehicle scan tool.

The vehicle scan tool can further update the received enhanced repairdata 330 by providing fault code and/or other data as part of diagnosticdata 360 as observed from the vehicle under repair, and send the furtherupdated enhanced repair data 330 to the server. Diagnostic data 360 canbe obtained using the software executables of the vehicle scan tools andthe related vehicle identifiers in enhanced repair data 330. The servercan examine the received diagnostic data 360 and update intelligentrepair data 380 of the received enhanced repair data 330 with PID lists,PID list identifiers, and identified tests, and send the even furtherupdated enhanced repair data 330 to the vehicle scan tool. The vehiclescan tool can obtain newly-observed data by scanning for the PIDs onsome or all of PID lists, obtaining data from a user, and/or executesome or all of the identified tests of the received intelligent repairdata 380, update diagnostic data 360 based on the newly-observed data,and send the updated enhanced repair data 330 to the server. The serverand vehicle scan tool can iterate on observed data (provided by thevehicle scan tool) and PID lists/tests provided (provided by the server)throughout a repair session to repair the vehicle under repair. Thus,the vehicle scan tool and server can communicate increasingly updatedversions of enhanced repair data 330 with each other to coordinaterepair activities during the repair session.

In the example shown in FIG. 3, intelligent repair data 380 includesthree PID list identifiers “A”, “B”, and “C” identifying respective PIDlists A, B, and C stored on the vehicle scan tool. Intelligent repairdata 380 also includes two identified tests: a component test “ComponentTest 1” and a functional tests “Functional Test A”. Many other PID listidentifiers identified tests, and/or intelligent repair data arepossible as well.

Some or all of intelligent repair data 380 can be provided to thevehicle scan tool from one or more servers communicatively coupled tothe vehicle scan tool. The vehicle scan tool and the server(s) cancommunicate some or all of intelligent repair data 380 to enable theserver to provide inputs, such as intelligent repair data 380, to thevehicle scan tool.

As one example, the vehicle scan tool can obtain data for common vehicleidentification, such as VIN or YMME data about a vehicle. Then, the scantool can update VID data 340 to include the data for common vehicleidentification and perhaps data about resident software executables. Thevehicle scan tool can then provide the enhanced repair data 330including updated VID data 340 to the server(s). The server(s) candetermine the vehicle identifiers for the software executables of thevehicle scan tool, and send enhanced repair data 330 with VID data 340that includes the vehicle identifiers for the software executables.

As another example, the vehicle scan tool can obtain diagnostic data byscanning for the PIDs listed on one or more PID lists identified byintelligent repair data 380 and/or by running some or all of theidentified tests specified by intelligent repair data 380. The vehiclescan tool can use the diagnostic data to update enhanced repair data330; e.g., update part or all of vehicle data 370, and send updatedenhanced repair data 330 to the server. The server can then receive thescan-tool-updated enhanced repair data 330, determine additionalidentified tests and/or PID lists based on updated enhanced repair data330, and update enhanced repair data 330 accordingly, e.g., updateintelligent repair data 380 to include the additional identified testsand/or PID lists. The server-updated enhanced repair data 330 can thenbe sent to the scan tool, for another iteration of updating the repairdata to be scan-tool-updated enhanced repair data 330, sending thescan-tool-updated enhanced repair data 330 to the server, and updatingthe scan-tool-updated repair data at the server to obtain newserver-updated enhanced repair data 330.

In some examples, vehicle identifier file 310 can be stored innon-volatile memory of a vehicle scan tool. Then, when the vehicle scantool has been requested to activate a software executable, the vehiclescan tool can open vehicle identifier file 310, find a name oridentifier of the requested software executable in software executablefield 320, and use the vehicle identifier 322 in the same entry as thefound name/identifier. For example, if the vehicle scan tool has beenrequested to activate a software executable whose name is “SE2”, thevehicle scan tool can open vehicle identifier file 310, find an entrywith the name “SE2” in the software executable field 320 of the vehicleidentifier file 310, and use the corresponding identifier “2012 Maker1Pickup Model1 4.6 L” in activating the requested software executable. Inother examples, a version of vehicle identifier file 310 can be storedin volatile memory; e.g., as a lookup table, and similar procedures canbe used to find vehicle identifiers associated with software executablesin volatile memory as used when vehicle identifier file 310 is stored innon-volatile memory.

In other examples, at least part of enhanced repair data 330 can bestored in volatile memory of the vehicle scan tool. In other examples, aversion of enhanced repair data 330 can be stored in non-volatile memoryof the vehicle scan tool; e.g., part or all of enhanced repair data 330can be stored in a file for purposes of backing up and/or restoring arepair session that is terminated by an inadvertent power down of thevehicle scan tool. In still other examples, as discussed above, at leastpart of enhanced repair data 330 can be communicated between and updatedby both the vehicle scan tool and a server to repair the vehicle.

FIG. 4 shows a communication flow 400 during repair of vehicle 410, inaccordance with an embodiment. During communication flow 400, technician416 repairs vehicle 410 using computing device 412 acting as and/orembodied as a vehicle scan tool to carry out method 200.

Communication flow 400 can begin at block 420, where computing device412 (acting as and/or embodied as a vehicle scan tool) can determinethat computing device 412 is not connected to either vehicle 410 orserver 414. In communications flows 400, 500, 600, and 700, computingdevice 412 is configured to but may or may not actually connect tovehicle 410 via a wired connection and is configured to but may or maynot actually connect to server 414 via a wireless connection. In othercommunication flows, computing device 412 can be configured to connectto vehicle 410 via wireless and/or other wired connections, and/orcomputing device 412 can be configured to connect to server 414 viawired and/or other wireless connections.

At block 422, computing device 412 can carry out the procedures of block210 of method 200 to determine that three software executables “SE1”,“SE2”, and “SE3” are resident on computing device 412. At block 430,computing device 412 can carry out the procedures of block 220 of method200 to obtain VII. In particular, at block 430, computing device 412 candisplay a VII entry page to a user of computing device 412; e.g.,technician 416, to obtain the VII from the user. Example pages forentering VII are shown as FIGS. 10A-10C.

After displaying the VII entry page, technician 416 provides VII data tocomputing device 412, as indicated in FIG. 4 as “VIN 410” of GetVIIRespmessage 432. That is, VIN 410 is data provided by technician 416 thatcorresponds to a VIN of vehicle 410. Upon reception of GetVIIRespmessage 432, computing device 412 obtains VIN 410 from message 432 andstores VIN 410 for later use.

At block 434, computing device 412 uses the procedures of block 230 ofmethod 200 to determine that computing device 412 is not connected to aserver. Then, computing device 412 uses the procedures of block 242 ofmethod 200 to generate a query Q400 for software executables SE1, SE2,SE3 on computing device 412, where query Q400 is based on VIN 410, andwhere software executables SE1, SE2, SE3 were previously identified atblock 422. Then, computing device 412 carries out the procedures ofblock 244 of method 200 to provide query Q400 to a local database (DB)resident on computing device 412 to obtain vehicle identifiers forsoftware executables SE1, SE2, SE3. The local database provides a queryresponse to query Q400 that includes vehicle identifiers VID1, VID2,VID3 for respective software executables SE1, SE2, SE3. By use of theprocedures of block 434, computing device 412 obtains vehicleidentifiers for all of its software executables at one time.

The local database can be useful when determining vehicle identifiersduring times computing device 412 is not connected to a server, such asserver 414. Other local repair-related data can be stored on computingdevice 412, where some or all of the local repair-related data can beused when computing device 412 is not connected to a server; e.g.,repair-related data for default content displays, default test selectiondata, default parameter list data, etc. In some embodiments, the localdatabase also stores some or all of the repair-related data.

At block 436, computing device 412 carries out the procedures of block250 of method 200 to save vehicle identifiers VID1, VID2, VID3. In theexample illustrated by communication flow 400, computing device 412 isnot connected to a server, so computing device 412 saves vehicleidentifiers VID1, VID2, VID3 to a vehicle identifier file F1 innon-volatile memory of computing device 412, such as discussed above inthe context of FIG. 3.

FIG. 4 shows that communication flow 400 continues with technician 416connecting computing device 412 with vehicle 410, as illustrated byconnect message 440. Then, at block 450, computing device 412 displays ahome page for vehicle repairs. An example vehicle repair home page isshown in FIG. 11 and discussed below.

After displaying the home page, technician 416 begins repair of vehicle410 by requesting activation of software executable SE1, illustrated inFIG. 4 by activate message 452. Computing device 412 uses the proceduresof block 260 of method 200 to receive activate message 452 requestingactivation of software executable SE1. In communication flow 400,software executable SE1 is a software executable for scanning a vehicle,such as vehicle 410, for information, where the information can include,but is not limited to, fault codes, PIDs, and values of parametersassociated with PIDs.

At block 454, computing device 412 uses the procedures of block 262 ofmethod 200 to retrieve a vehicle identifier VID1 associated withsoftware executable SE1. Then, computing device 412 uses the proceduresof block 264 of method 200 to provide VID1 to software executable SE1while starting software executable SE1.

Communication flow 400 continues with technician 416 using an interfaceto software executable SE1 to send GetFaultCodes message 460 tocomputing device 412. Computing device 412 then requests fault codesfrom vehicle 410 via software executable SE1 using GetFaultCodes message462 that corresponds to GetFaultCodes message 460. In response toGetFaultCodes message 462, software executable SE1 obtains fault codesFC1 and FC2 from vehicle 410, as indicated in FIG. 4 as part ofFaultCodes message 464. In other scenarios, more, fewer, and/ordifferent fault codes than FC1 and FC2 can be provided; e.g., inFaultCodes message 464.

At block 466, computing device 412 displays FC1 and FC2 on a repairpage. The repair page can be a display associated with softwareexecutable SE1. An example repair page displaying fault codes is shownis shown in FIG. 12 and discussed below. An example of carrying out theprocedures of block 270 of method 200 can include the repairs to vehicle410 associated with messages 452, 460, 462, 464, and blocks 454, 466.

After display of the repair page with fault codes FC1 and FC2,technician 416 requests repair information about fault code FC1, asillustrated using GetRepairInfo message 468 with data of “FC1”. In othercommunications flows, technician 416 can request information aboutmultiple fault codes via GetRepairInfo message 468. At block 470,computing device 412 responds to GetRepairInfo message 468 by displayinga repair page for fault code FC1. An example repair page for a faultcode is shown in FIG. 13A discussed below.

FIG. 4 illustrates that after the repair page for fault code FC1 isdisplayed, technician 416 requests activation of software executable SE2as illustrated using activate message 480 with data of “SE2”. Computingdevice 412 uses the procedures of block 280 and then block 260 of method200 to receive activate message 480 requesting activation of softwareexecutable SE2. In communication flow 400, software executable SE2 is asoftware executable for performing component tests on a vehicle, such asvehicle 410.

At block 482, computing device 412 uses the procedures of block 262 ofmethod 200 to retrieve a vehicle identifier VID2 associated withsoftware executable SE2 from file F1. Then, computing device 412 usesthe procedures of block 264 of method 200 to provide VID2 to softwareexecutable SE2 while starting software executable SE2.

At block 484, computing device 412 displays one or more component testsC1, C2 . . . Cn that can be selected for execution. In some examples,some or all of component tests C1, C2 . . . Cn available for possibleexecution can themselves be selected based on fault code FC1 selected asdiscussed above in the context of GetRepairInfo message 468.

After displaying the one or more possible component tests, technician416 uses an interface to software executable SE2 to send TestComponentmessage 486 to computing device 412 to request execution of componenttest “C1” of vehicle 410.

Upon reception of TestComponent message 486, communication flow 400 canbe completed. An example of carrying out the procedures of block 270 ofmethod 200 can include the repairs to vehicle 410 associated with block484 and message 486.

Subsequently, computing device 412 can use the procedures of block 280of method 200 to complete communication flow 400. In other examples, therepairs to vehicle 410 at block 270 of method 200 include carrying outone or more component tests of component C1 of vehicle 410 anddetermining one or more results to the component tests of component C1as directed by TestComponent message 486.

FIG. 5 shows a communication flow 500 during repair of vehicle 410, inaccordance with an embodiment. During communication flow 500, technician416 repairs vehicle 410 using computing device 412 acting as a vehiclescan tool to carry out aspects of method 200. Communication flow 500 isrelated to communication flow 400 discussed immediately above. Incommunication flow 400, all vehicle identifiers for software executableswere determined at one time, while in communication flow 500, vehicleidentifiers for software executables are determined as needed; that is,upon activation of a software executable.

Communication flow 500 can begin at block 520, where computing device412 (acting as a vehicle scan tool) can determine that computing device412 is not connected to either vehicle 410 or server 414. At block 530,computing device 412 can carry out the procedures of block 220 of method200 to obtain VII. In particular, at block 530, computing device 412 candisplay a VII entry page to a user of computing device 412 as discussedabove in the context of block 430 of communication flow 400.

After displaying the VII entry page, technician 416 provides VII data tocomputing device 412, as indicated in FIG. 5 as “VIN 410” of GetVIIRespmessage 532. That is, VIN 410 is data provided by technician 416 thatcorresponds to a VIN of vehicle 410. Upon reception of GetVIIRespmessage 532, computing device 412 obtains VIN 410 from message 532 andstores VIN 410 for later use.

FIG. 5 shows that communication flow 500 continues with technician 416connecting computing device 412 with vehicle 410, as illustrated in FIG.5 by connect message 540. Then, at block 542, computing device 412displays a home page for vehicle repairs as discussed above in thecontext of block 450 of communication flow 400.

After displaying the home page, technician 416 begins repair of vehicle410 by requesting activation of software executable SE1, illustrated inFIG. 5 by activate message 550. Computing device 412 uses the proceduresof block 260 of method 200 to receive activate message 550 requestingactivation of software executable SE1. In communication flow 500,software executable SE1 is the same software executable for scanning avehicle as software executable SE1 discussed above in the context ofcommunication flow 400.

Upon reception of activate message 550, computing device 412 carries outthe procedures of block 552 to determine that a vehicle identifier forsoftware executable SE1 is not yet available; e.g., computing device 412determines that a vehicle identifier file with a vehicle identifier forsoftware executable SE1 is not available. Then, computing device 412carries out the procedures of block 230 of method 200 to determine thatcomputing device 412 is not connected to a server. After determiningthat the vehicle identifier for SE1 is not available and determiningcomputing device 412 is not connected to a server, computing device 412retrieves VIN 410 from storage as indicated in the context of message532. Then, computing device 412 uses the procedures of block 242 ofmethod 200 to generate a query Q501 for software executable SE1 oncomputing device 412, where query Q501 is based on retrieved VIN 410,and where software executable SE1 was identified by activate message550. In some examples, computing device 412 verifies that softwareexecutable SE1 is resident on computing device before generating queryQ501—in examples where software executable SE1 is not resident,computing device 412 can generate and display an appropriate errormessage.

At block 554, computing device 412 carries out the procedures of block244 of method 200 to provide query Q501 to a local database resident oncomputing device 412 to obtain a vehicle identifier for softwareexecutable SE1. Then, the local database provides a query response toquery Q501 that includes vehicle identifier VID1 for software executableSE1.

At block 556, computing device 412 carries out the procedures of block250 of method 200 to save vehicle identifier VID1. In the exampleillustrated by communication flow 400, computing device 412 is notconnected to a server, so computing device 412 saves vehicle identifierVID1 to a vehicle identifier file F1 stored in non-volatile memory ofcomputing device 412, such as discussed above in the context of FIGS. 3and 4.

At block 558, computing device 412 uses the procedures of block 264 ofmethod 200 to provide VID1 to software executable SE1 while startingsoftware executable SE1.

Communication flow 500 continues with technician 416 using an interfaceto software executable SE1 to send GetFaultCodes message 560 tocomputing device 412. Computing device 412 then requests fault codesfrom vehicle 410 via software executable SE1 using GetFaultCodes message562 that corresponds to GetFaultCodes message 560. In response toGetFaultCodes message 562, software executable SE1 obtains fault codesFC1 and FC2 from vehicle 410, as indicated in FIG. 4 as FaultCodesmessage 564. In other scenarios, more, fewer, and/or different faultcodes than FC1 and FC2 can be provided; e.g., in FaultCodes message 564.

At block 566, computing device 412 displays FC1 and FC2 on a repairpage, such as discussed above in the context of block 466 ofcommunication flow 400. An example of carrying out the procedures ofblock 270 of method 200 can include the repairs to vehicle 410associated with messages 550, 560, 562, 564 and blocks 552, 554, 556,558, 566.

After display of the repair page with fault codes FC1 and FC2,technician 416 requests repair information about fault code FC1, asillustrated using GetRepairInfo message 568 with data of “FC1”. At block570, computing device 412 responds to GetRepairInfo message 568 bydisplaying a repair page for fault code FC1 as discussed above in thecontext of block 470 of communication flow 400.

FIG. 5 illustrates that after the repair page for fault code FC1 isdisplayed, technician 416 requests activation of software executable SE2as illustrated using activate message 572 with data of “SE2”. Incommunication flow 500, software executable SE2 is the same softwareexecutable for performing component tests as software executable SE2discussed above in the context of communication flow 400.

Upon reception of activate message 572, computing device 412 carries outthe procedures of block 574 to determine that a vehicle identifier forsoftware executable SE2 is not yet available; e.g., computing device 412determines that a vehicle identifier file with a vehicle identifier forsoftware executable SE2 is not available. Then, computing device 412carries out the procedures of block 230 of method 200 to determine thatcomputing device 412 is not connected to a server. After determiningthat the vehicle identifier for SE2 is not available and determiningcomputing device 412 is not connected to a server, computing device 412retrieves VIN 410 from storage after receiving GetVIIResp message 532.Then, computing device 412 uses the procedures of block 242 of method200 to generate a query Q502 for software executable SE2 on computingdevice 412, where query Q502 is based on retrieved VIN 410, and wheresoftware executable SE2 was identified by activate message 572. In someexamples, computing device 412 verifies that software executable SE2 isresident on computing device before generating query Q502—in exampleswhere software executable SE2 is not resident, computing device 412 cangenerate and display an appropriate error message.

At block 576, computing device 412 carries out the procedures of block244 of method 200 to provide query Q502 to the local database to obtaina vehicle identifier for software executable SE2. Then, the localdatabase provides a query response to query Q502 that includes vehicleidentifier VID2 for software executable SE2.

At block 578, computing device 412 carries out the procedures of block250 of method 200 to save vehicle identifier VID2 to the vehicleidentifier file F1 as computing device 412 is not connected to a server,so computing device 412 saves vehicle identifier VID1 to a vehicleidentifier file F1 stored in non-volatile memory of computing device412, such as discussed above in the context of FIGS. 3 and 4.

At block 580, computing device 412 uses the procedures of block 264 ofmethod 200 to provide VID2 to software executable SE2 while startingsoftware executable SE2.

At block 582, computing device 412 displays one or more component testsC1, C2 . . . Cn that can be selected for execution. In some examples,some or all of component tests C1, C2 . . . Cn available for possibleexecution can themselves be selected based on fault code FC1 selected asdiscussed above in the context of GetRepairInfo message 568. Afterdisplaying the one or more component tests that can be selected forexecution, technician 416 uses an interface to software executable SE2to send TestComponent message 584 to computing device 412 to requestexecution of component test “C1” of vehicle 410.

Upon reception of TestComponent message 584, computing device 412performs the requested component test C1. An example of carrying out theprocedures of block 270 of method 200 can include the repairs to vehicle410 associated with messages 572, 584 and blocks 574, 576, 578, 580,582.

Communication flow 500 continues with technician 416 requestingactivation of software executable SE1 as illustrated using activatemessage 590 with data of “SE1”. Upon reception of activate message 590,computing device 412 carries out the procedures of block 592 todetermine that a vehicle identifier for software executable SE1 isavailable in file F1, and so retrieves vehicle identifier VID1 from fileF1. Then, computing device 412 uses the procedures of block 264 ofmethod 200 to provide VID1 to software executable SE1 while startingsoftware executable SE1.

Communication flow 500 continues with technician 416 using an interfaceto software executable SE1 to send GetFaultCodes message 594 tocomputing device 412. The repairs to vehicle 410 at block 270 of method200 include obtaining fault codes from vehicle 410, as directed bymessage 594, and displaying any obtained fault codes.

Upon reception of GetFaultCodes message 594 and perhaps displaying anyobtained fault codes by computing device 412, computing device 412 canuse the procedures of block 280 of method 200 to complete communicationflow 500.

FIG. 6 shows a communication flow 600 during repair of vehicle 410, inaccordance with an embodiment. During communication flow 600, technician416 repairs vehicle 410 using computing device 412 acting as and/orembodied as a vehicle scan tool to carry out method 200. Communicationflow 600 is related to communication flow 400. In communication flow400, computing device 412 was not connected to server 414 and was notconnected to vehicle 410 initially. However, in communication flow 600,computing device 412 connects to vehicle 410 and server 414 at theonset.

In communication flows 600 and 700 (shown in FIG. 7), respective repairsessions are begun when computing device 412 connects to vehicle 410 andserver 414 and lasts throughout respective communication flows 600 and700. In other examples, a repair session can be interrupted. Forexample, a repair session can last until computing device 412 is poweredoff, until new fault codes and/or parameter values are selected and/orobtained, until computing device 412 connects to a different vehiclethan vehicle 410, until a pre-determined amount of time after connectionof computing device 412 to vehicle 410 and/or server 414 has elapsed,and/or last until other condition(s) are met. In some particularexamples, a relatively-brief interruption (e.g., 30 seconds or less, 1minute or less, 30 minutes or less) of a connection between vehicle 410and server 414 may be ignored in determining that a repair session hasended. For example, computing device 412 can move during a repairsession and lose connectivity while moving, leading to re-establishingcommunication with server 414 after moving—such brief interruptions canbe ignored when determining whether a repair session has ended.

FIG. 6 shows that communication flow 600 begins with technician 416connecting computing device 412 (acting as and/or embodied as a vehiclescan tool) with vehicle 410 as illustrated by connect message 620.Computing device 412 also connects with server 414 as illustrated byconnect message 622.

At block 630, computing device 412 can carry out the procedures of block210 of method 200 to determine that three software executables “SE1”,“SE2”, and “SE3” are resident on computing device 412. Computing device412 can then send GetVII message 632 to vehicle 410 to obtainVII-related information, such as a VIN of vehicle 410, in accord withthe procedures of block 220 of method 200. Vehicle 410 responds withGetVIIResp message 634 that includes VIN 410, which is the VIN ofvehicle 410. Computing device 412 then obtains VIN 410 from GetVIIRespmessage 634.

At block 640, computing device 412 carries out the procedures of block230 of method 200 to determine that computing device 412 is connected toa server; e.g., server 410. Computing device 412 then uses theprocedures of block 232 of method 200 to generate a query Q600 forsoftware executables SE1, SE2, SE3 on computing device 412, where queryQ600 is based on VIN 410, and where software executables SE1, SE2, SE3were previously identified at block 630. Computing device 412 alsocarries out the procedures of block 234 of method 200 to provide queryQ600 to server 414 to obtain vehicle identifiers for softwareexecutables SE1, SE2, SE3 via QueryDB message 642.

In response to query Q600 in QueryDB message 642, server 414 sendsRepairinfoResp message 644 with enhanced repair data ERD that includesvehicle identifiers VID1, VID2, VID3 for respective software executablesSE1, SE2, SE3. An example format of enhanced repair data is shown inFIG. 3 discussed above. By use of messages 642 and 644, computing device412 obtains vehicle identifiers for all of its software executables atone time. In communication flow 600, computing device 412 saves ERD tostorage, thereby saving vehicle identifiers VID1, VID2, VID3 to storage.

Then, at block 650, computing device 412 displays a home page forvehicle repairs. An example vehicle repair home page is shown in FIG. 11and discussed below.

After displaying the home page, technician 416 begins repair of vehicle410 by requesting activation of software executable SE1, illustrated inFIG. 6 by activate message 652. In communication flow 600, softwareexecutable SE1 is the same software executable for scanning a vehicle assoftware executable SE1 discussed above in the context of communicationflow 400.

Computing device 412 uses the procedures of block 260 of method 200 toreceive activate message 652 requesting activation of softwareexecutable SE1. In communication flow 600, software executable SE1 is asoftware executable for scanning a vehicle, such as vehicle 410, forinformation, where the information can include, but is not limited to,fault codes, PIDs, and values of parameters associated with PIDs.

At block 654, computing device 412 uses the procedures of block 262 ofmethod 200 to retrieve a vehicle identifier VID1 associated withsoftware executable SE1 from stored enhanced repair data ERD. Then,computing device 412 uses the procedures of block 264 of method 200 toprovide VID1 to software executable SE1 while starting softwareexecutable SE1.

Communication flow 600 continues with technician 416 using an interfaceto software executable SE1 to send GetFaultCodes message 660 tocomputing device 412. Computing device 412 then requests fault codesfrom vehicle 410 via software executable SE1 using GetFaultCodes message662 that corresponds to GetFaultCodes message 660. In response toGetFaultCodes message 662, software executable SE1 obtains fault codesFC1 and FC2 from vehicle 410 as part of FaultCodes message 664.

At block 666, computing device 412 displays FC1 and FC2 on a repairpage. The repair page can be a display associated with softwareexecutable SE1. An example repair page displaying fault codes is shownis shown in FIG. 12 and discussed below. Also, computing device adds FC1and FC2 to ERD at block 666. An example of carrying out the proceduresof block 270 of method 200 can include the repairs to vehicle 410associated with messages 652, 660, 662, 664 and blocks 654, 666.

After display of the repair page with fault codes FC1 and FC2,technician 416 requests repair information about fault code FC1, asillustrated using GetRepairInfo message 670 with data of “FC1”. At block672, computing device 412 responds to GetRepairInfo message 670 byupdating enhanced repair data ERD to indicate that FC1 is a currentfault code (FC). In other communications flows, technician 416 canrequest information about multiple fault codes via GetRepairInfo message670; in these flows, computing device 412 can update enhanced repairdata ERD to indicate that multiple fault codes are current fault codes.

Then, computing device 412 sends GetRepairInfo message 674 with enhancedrepair data ERD as updated at block 672 to server 414. Server 414 thensends RepairinfoResp message 676 with updated enhanced repair data ERD2that includes PID lists and tests associated with fault code FC1. Inparticular, some or all of component tests C1, C2 . . . Cn can beselected by server 414 based on fault code FC1. Then, server 414 canupdate enhanced repair data ERD2 by adding selected component tests C1,C2 . . . Cn to ERD2 before sending RepairinfoResp message 676. Uponreception of enhanced repair data ERD2, computing device 412 stores acopy of ERD2.

At block 678, computing device 412 displays a repair page for fault codeFC1. An example repair page for a fault code is shown in FIG. 13Adiscussed below.

Communication flow 600 continues with technician 416 requestingactivation of software executable SE2 as illustrated using activatemessage 680 with data of “SE2”. In communication flow 600, softwareexecutable SE2 is the same software executable for performing componenttests as software executable SE2 discussed above in the context ofcommunication flow 400.

Computing device 412 uses the procedures of block 280 and then block 260of method 200 to receive activate message 680 requesting activation ofsoftware executable SE2. In communication flow 600, software executableSE2 is a software executable for performing component tests on avehicle, such as vehicle 410.

At block 682, computing device 412 uses the procedures of block 262 ofmethod 200 to retrieve a vehicle identifier VID2 associated withsoftware executable SE2 and retrieve component test selections C1, C2 .. . Cn from the stored copy of enhanced repair data ERD2. Then,computing device 412 uses the procedures of block 264 of method 200 toprovide VID2 to software executable SE2 while starting softwareexecutable SE2.

At block 684, computing device 412 displays one or more component testsC1, C2 . . . Cn that can be selected for execution. After displaying theone or more possible component tests, technician 416 uses an interfaceto software executable SE2 to send TestComponent message 686 tocomputing device 412 to request execution of component test “C1” ofvehicle 410.

Upon reception of TestComponent message 686, communication flow 600 canbe completed. An example of carrying out the procedures of block 270 ofmethod 200 can include the repairs to vehicle 410 associated with block684 and message 686.

Subsequently, computing device 412 can use the procedures of block 280of method 200 to complete communication flow 600. In other examples, therepairs to vehicle 410 at block 270 of method 200 include carrying outcomponent test C1 of vehicle 410 and determining one or more results tocomponent test C1 as directed by TestComponent message 686.

FIG. 7 shows a communication flow 700 during repair of vehicle 410, inaccordance with an embodiment. During communication flow 700, technician416 repairs vehicle 410 using computing device 412 acting as and/orembodied as a vehicle scan tool to carry out aspects of method 200.

Communication flow 700 is related to communication flow 500. Incommunication flow 500, computing device 412 was not connected to server414 and was not initially connected to vehicle 410. However, incommunication flow 700, computing device 412 connects to vehicle 410 andserver 414 at the onset.

FIG. 7 shows that communication flow 700 begins with technician 416connecting computing device 412 (acting as and/or embodied as a vehiclescan tool) with vehicle 410 as illustrated by connect message 710.Computing device 412 also connects with server 414 as illustrated byconnect message 712.

Computing device 412 can send GetVII message 720 to vehicle 410 toobtain VII-related information, such as a VIN of vehicle 410, in accordwith the procedures of block 220 of method 200. Vehicle 410 respondswith GetVIIResp message 722 that includes VIN 410, which is the VIN ofvehicle 410. Computing device 412 then obtains VIN 410 from GetVIIRespmessage 722 and stores VIN 410 for later use.

At block 724, computing device 412 displays a home page for vehiclerepairs as discussed above in the context of block 450 of communicationflow 400.

After displaying the home page, technician 416 begins repair of vehicle410 by requesting activation of software executable SE1, illustrated inFIG. 5 by activate message 730. Computing device 412 uses the proceduresof block 260 of method 200 to receive activate message 730 requestingactivation of software executable SE1. In communication flow 700,software executable SE1 is the same software executable for scanning avehicle as software executable SE1 discussed above in the context ofcommunication flow 400.

Upon reception of activate message 730, computing device 412 carries outthe procedures of block 732 to determine that a vehicle identifier forsoftware executable SE1 is not yet available; e.g., computing device 412determines that a vehicle identifier file or enhanced repair data havinga vehicle identifier for software executable SE1 is not available. Then,computing device 412 carries out the procedures of block 230 of method200 to determine that computing device 412 is connected to a server;e.g., server 410.

After determining that the vehicle identifier for SE1 is not availableand that computing device 412 is connected to a server, computing device412 retrieves VIN 410 that was stored after receiving GetVIIResp message730. Still at block 732, computing device 412 uses the procedures ofblock 232 of method 200 to generate a query Q701 for software executableSE1 on computing device 412, where query Q701 is based on retrieved VIN410, and where software executable SE1 was identified by activatemessage 730. In some examples, computing device 412 verifies thatsoftware executable SE1 is resident on computing device beforegenerating query Q701—in examples where software executable SE1 is notresident, computing device 412 can generate and display an appropriateerror message. Computing device 412 also carries out the procedures ofblock 234 of method 200 to provide query Q701 to server 414 to obtain avehicle identifier for software executable SE1 using QueryDB message734.

In response to query Q701 in QueryDB message 734, server 414 sendsRepairinfoResp message 736 with enhanced repair data ERD that includesvehicle identifier VID1 for software executable SE1. An example formatof enhanced repair data is shown in FIG. 3 discussed above. Uponreception of enhanced repair data ERD, computing device 412 saves ERD tostorage, thereby saving vehicle identifier VID1 to storage.

At block 738, computing device 412 uses the procedures of block 262 ofmethod 200 to retrieve a vehicle identifier VID1 associated withsoftware executable SE1 from stored enhanced repair data ERD. Then,computing device 412 uses the procedures of block 264 of method 200 toprovide VID1 to software executable SE1 while starting softwareexecutable SE1.

Communication flow 700 continues with technician 416 using an interfaceto software executable SE1 to send GetFaultCodes message 740 tocomputing device 412. Computing device 412 then requests fault codesfrom vehicle 410 via software executable SE1 using GetFaultCodes message742 that corresponds to GetFaultCodes message 740. In response toGetFaultCodes message 742, vehicle 410 provides fault codes FC1 and FC2as part of FaultCodes message 744.

At block 746, computing device 412 displays FC1 and FC2 on a repairpage. The repair page can be a display associated with softwareexecutable SE1. An example repair page displaying fault codes is shownis shown in FIG. 12 and discussed below. Also, computing device adds FC1and FC2 to ERD at block 746. An example of carrying out the proceduresof block 270 of method 200 can include the repairs to vehicle 410associated with messages 730, 734, 736, 740, 742, 744 and blocks 732,738, 746.

After display of the repair page with fault codes FC1 and FC2,technician 416 requests repair information about fault code FC1, asillustrated using GetRepairInfo message 750 with data of “FC1”. At block752, computing device 412 responds to GetRepairInfo message 750 byupdating ERD to indicate that FC1 is a current fault code (FC). In othercommunications flows, technician 416 can request information aboutmultiple fault codes via GetRepairInfo message 750; in these flows,computing device 412 can update enhanced repair data ERD to indicatethat multiple fault codes are current fault codes.

Then, computing device 412 sends GetRepairInfo message 754 with enhancedrepair data ERD as updated at block 752 to server 414. Server 414 thensends RepairinfoResp message 756 with updated enhanced repair data ERD2that includes PID lists and tests associated with fault code FC1. Inparticular, some or all of component tests C1, C2 . . . Cn can beselected by server 414 based on fault code FC1. Then, server 414 canupdate enhanced repair data ERD2 by adding selected component tests C1,C2 . . . Cn to ERD2 before sending RepairinfoResp message 756. Uponreception of enhanced repair data ERD2, computing device 412 stores acopy of ERD2.

At block 758, computing device 412 displays a repair page for fault codeFC1. An example repair page for a fault code is shown in FIG. 13Adiscussed below.

Communication flow 700 continues with technician 416 requestingactivation of software executable SE2 as illustrated using activatemessage 760 with data of “SE2”. In communication flow 700, softwareexecutable SE2 is the same software executable for performing componenttests as software executable SE2 discussed above in the context ofcommunication flow 400.

Upon reception of activate message 760, computing device 412 carries outthe procedures of block 762 to determine that a vehicle identifier forsoftware executable SE2 is not yet available; e.g., computing device 412determines enhanced repair data ERD2 does not store a vehicle identifierfor software executable SE2. Then, computing device 412 carries out theprocedures of block 230 of method 200 to determine that computing device412 is connected to a server. After determining that the vehicleidentifier for SE2 is not available and determining computing device 412is connected to a server, computing device 412 retrieves VIN 410 thatwas stored after receiving GetVIIResp message 730. Then, computingdevice 412 uses the procedures of block 232 of method 200 to generate aquery Q702 for software executable SE2 on computing device 412, wherequery Q702 is based on retrieved VIN 410, and where software executableSE2 was identified by activate message 760. In some examples, computingdevice 412 verifies that software executable SE2 is resident oncomputing device before generating query Q702—in examples where softwareexecutable SE2 is not resident, computing device 412 can generate anddisplay an appropriate error message.

Computing device 412 then carries out the procedures of block 234 ofmethod 200 to provide query Q702 to server 414 to obtain a vehicleidentifier for software executable SE2 using QueryDB message 764. Inresponse to query Q702 in QueryDB message 764, server 414 sendsRepairinfoResp message 766 with enhanced repair data ERD3 that includesvehicle identifier VID2 for software executable SE2. Upon reception ofenhanced repair data ERD3, computing device 412 can save a copy of ERD3to storage, thereby storing vehicle identifier VID2

At block 770, computing device 412 uses the procedures of block 262 ofmethod 200 to retrieve a vehicle identifier VID2 associated withsoftware executable SE2 and retrieve component test selections C1, C2 .. . Cn from the stored copy of enhanced repair data ERD3. Then,computing device 412 uses the procedures of block 264 of method 200 toprovide VID2 to software executable SE2 while starting softwareexecutable SE2.

At block 772, computing device 412 displays one or more component testsC1, C2 . . . Cn that can be selected for execution. After displaying theone or more possible component tests, technician 416 uses an interfaceto software executable SE2 to send TestComponent message 774 tocomputing device 412 to request execution of component test “C1” ofvehicle 410.

Upon reception of TestComponent message 774, computing device 412performs the requested component test C1. An example of carrying out theprocedures of block 270 of method 200 can include the repairs to vehicle410 associated with messages 760, 764, 766, 774 and blocks 762, 770,772.

Communication flow 700 continues with technician 416 requestingactivation of software executable SE1 as illustrated using activatemessage 780 with data of “SE1”.

Upon reception of activate message 780, computing device 412 carries outthe procedures of block 782 to determine that a vehicle identifier forsoftware executable SE1 is available in enhanced repair data ERD3 and toretrieve a vehicle identifier VID1 associated with software executableSE1 from enhanced repair data ERD3. Then, computing device 412 uses theprocedures of block 264 of method 200 to provide VID1 to softwareexecutable SE1 while starting software executable SE1.

Communication flow 700 continues with technician 416 using an interfaceto software executable SE1 to send GetFaultCodes message 784 tocomputing device 412. The repairs to vehicle 410 at block 270 of method200 include obtaining fault codes from vehicle 410, as directed bymessage 784, and displaying any obtained fault codes. Upon reception ofGetFaultCodes message 784 and perhaps displaying any obtained faultcodes by computing device 412, computing device 412 can use theprocedures of block 280 of method 200 to complete communication flow700.

In some examples, software executables stored on computing device 412can include more, fewer, and/or different software executables than SE1,SE2, and SE3 as described in the context of communications flows 400,500, 600, 700. In other examples, more, fewer, and/or different vehicleidentifiers can be associated with software executables resident oncomputing device 412.

Example Common Vehicle Identification and Repair Scenarios

FIGS. 8, 9, 10A, 10B, 10C, 11, 12, 13A, 13B, 13C, 13D, 13E, 14A, 14B,14C, and 14D show two related scenarios 800, 800 a, where computingdevice 412, embodied as a vehicle scan tool, is used by a technicianTech1, such as technician 416, to repair a vehicle V1, such as vehicle410, in accordance with an embodiment. Scenarios 800 and 800 aillustrate some details of how computing device 412 is used to repairthe vehicle; e.g., by scanning for DTCs/PIDs, executing tests, reportingtest results, and making other repair-related information available totechnician Tech1 working on vehicle V1.

During scenario 800, computing device 412 is connected to one server S1,such as server 414, such as discussed above at least in the context ofcommunication flows 600 and 700. As such, scenario 800 is related to,and illustrates aspects of communication flows 600 and 700. However,during scenario 800 a, computing device 412 is not connected to a serverand initially is not connected to vehicle V1, such as discussed above atleast in the context of communication flows 400 and 500. As such,scenario 800 a is related to, and illustrates aspects of communicationflows 400 and 500.

In scenario 800, server S1 provides information as requested bycomputing device 412, which can involve obtaining the information onbehalf of computing device 412 from one or more other server(s). Inother scenarios, computing device 412 can communicate with multipleservers; e.g., a server for common vehicle identification, a server forgenerating enhanced repair information, a server for providing items ofvehicle information, etc.

For both scenarios 800 and 800 a, computing device 412 has at leastthree resident software executables: (1) an adaptive PID scannerexecutable for scanning a vehicle for information associated withvehicle identifier V_SE, (2) a component test executable for performingcomponent tests on a vehicle associated with a vehicle identifier V_CTE,and (3) a functional test executable for performing functional tests ona vehicle associated with a vehicle identifier V_FTE. In both scenarios800 and 800 a, the only user of computing device 412 is technicianTech1.

Scenarios 800 and 800 a begin with computing device 412 providing adialog for common vehicle identification. In scenario 800, computingdevice 412 communicates with vehicle V1 to obtain VII and communicateswith server S1 to obtain vehicle identifiers for software executablesresident on computing device 412; e.g., vehicle identifiers V_SE, V_CTE,and V_FTE. In scenario 800 a, technician Tech1 provides inputs relatedto the VII and once the VII is obtained, computing device 412 uses alocal database stored on computing device 412 to obtain vehicleidentifiers for software executables resident on computing device 412;e.g., vehicle identifiers V_SE, V_CTE, and V_FTE.

In scenarios 800 and 800 a, computing device 412 obtains vehicleidentifiers V_SE, V_CTE, and V_FTE all at once, such as discussed abovein the context of respective communication flows 400 and 600. In otherscenarios, computing device 412 obtains vehicle identifiers as neededfrom server S1 or from the local database, as discussed above in thecontext of respective communication flow 500 or communication flow 700.In scenario 800 a, after the vehicle identifiers for softwareexecutables resident on computing device have been obtained, computingdevice 412 is connected to vehicle V1. In other scenarios than scenario800 a, computing device 412 is connected to vehicle V1 before thevehicle identifiers for software executables resident on computingdevice have been obtained.

After the vehicle identifiers are obtained and vehicle V1 is connectedto computing device 412, both scenarios 800 and 800 a continue withcomputing device 412 presenting a vehicle repair home page. For bothscenarios 800 and 800 a, technician Tech1 requests activation of theadaptive PID scanner executable from the vehicle repair home page. Inresponse, computing device 412 retrieves vehicle identifier V_SE fromstorage, computing device 412 provides vehicle identifier V_SE to theadaptive PID scanner executable during activation, and the adaptive PIDscanner executable obtains three DTCs from vehicle V1. In otherscenarios, more, fewer, and/or different DTCs than discussed in thecontext of scenarios 800 and 800 a are obtained from a vehicle.

Computing device 412 subsequently displays a scanner executable pagewith three controls for the respective obtained DTCs on the scannerexecutable page. For both scenarios 800 and 800 a, a selection for DTCP0171 is selected by technician Tech1 from the scanner executable page.

Scenario 800 continues with computing device 412 communicating with theserver to obtain more information related to DTC P0171 and subsequentlydisplays a repair page based on the information obtained from theserver. From the repair page, technician Tech1 requests activation ofthe component test executable. In response, computing device 412displays a repair page for the component test executable which is alsobased on the information related to DTC P0171 obtained from the server.After displaying the repair page for the component test executable,technician Tech1 selects a component test from the repair page.Consequently, computing device 412 retrieves vehicle identifier V_CTEfrom storage and provides vehicle identifier V_CTE to the component testexecutable. The component test executable then executes a component teston vehicle V1.

Scenario 800 then proceeds with technician Tech1 requesting activationof the functional test executable. Computing device 412 displays arepair page for the functional test executable which is also based onthe information related to DTC P0171 obtained from the server. Afterdisplaying the repair page for the functional test executable,technician Tech1 selects a functional test from the repair page.Consequently, computing device 412 retrieves vehicle identifier V_FTEfrom storage and provides vehicle identifier V_FTE to the functionaltest executable. The functional test executable then executes afunctional test on vehicle V1.

After the functional test is completed, technician Tech1 selects use ofthe adaptive PID scanner from the default repair page. Consequently,computing device 412 retrieves vehicle identifier V_SE from storage andprovides vehicle identifier V_SE to the adaptive PID scanner executable.The adaptive PID scanner executable then obtains PID data for parameterslisted on a PID list provided by server S1 and displays the obtained PIDdata in a repair page.

After displaying the obtained PID data, scenario 800 continues withtechnician Tech1 requesting a repair page for DTC C0660 that isunrelated to DTC P0171—computing device 412 attempts to obtaininformation from the server related to DTC C0660, but the serverdetermines no information is available for DTC C0660. Subsequently,computing device 412 provides a repair page indicating information fromthe server is unavailable for DTC C0660. After providing this repairpage, scenario 800 is completed.

Returning to scenario 800 a, the scenario continues with computingdevice 412 receiving the selection for DTC P0171 and providing a firstdefault repair page related to DTC P0171. As indicated above, a defaultpage is not based on information from the server (as computing device412 is not connected to the server during scenario 800 a). From thefirst default repair page, technician Tech1 requests activation of thecomponent test executable and computing device 412 displays anotherdefault repair page for the component test executable. After displayingthe default repair page for the component test executable, technicianTech1 selects a component test from the default repair page.Consequently, computing device 412 retrieves vehicle identifier V_CTEfrom storage and provides vehicle identifier V_CTE to the component testexecutable. The component test executable then executes a component teston vehicle V1.

Scenario 800 a then proceeds with technician Tech1 requesting activationof the functional test executable. Computing device 412 displays adefault repair page for the functional test executable. After displayingthe default repair page for the functional test executable, technicianTech1 selects a functional test from the repair page. Consequently,computing device 412 retrieves vehicle identifier V_FTE from storage andprovides vehicle identifier V_FTE to the functional test executable. Thefunctional test executable then executes a functional test on vehicleV1.

After the functional test is completed, technician Tech1 selects use ofthe PID scanner from the default repair page. Consequently, computingdevice 412 retrieves vehicle identifier V_SE from storage and providesvehicle identifier V_SE to the adaptive PID scanner executable. Theadaptive PID scanner executable then obtains PID data for parameterslisted on a default PID list and displays the obtained data in a repairpage. After displaying the repair page that has PID data for parameterslisted on the default PID list, scenario 800 a is completed.

Turning to FIG. 8, scenarios 800 and 800 a begin with computing device412 presenting dialog 810 for “common vehicle identification”, wheredialog 810 includes an “OK” button 812. Dialog 810 states that “[to] useoptional automatic common vehicle identification, connect scan tool toOBD port of vehicle before proceeding” and that technician Tech1 should“[press] OK [button 812] when ready to proceed.

Scenario 800 continues with technician Tech1 connecting vehicle V1 tocomputing device 412 prior to pressing OK button 812. Scenario 800 thenproceeds with computing device 412 presenting dialog 910 as shown inFIG. 9. Dialog 910 relates to “automatic common vehicle identification”.During automatic common vehicle identification, computing device 412 can“[i]dentif[y] resident software executables” to find “softwareexecutables: SE1, SE2, SE3” as indicated by dialog 910. In scenarios 800and 800, software executable SE1 is the adaptive PID scanner executable,software executable SE2 is the component test executable, and softwareexecutable SE3 is the functional test executable.

Dialog 910 shows that computing device 412 can “[get] vehicleinformation from connected vehicle” that includes a“VIN=XXXXXXXXXXXXXXXXX”, which is a VIN for a “[v]ehicle identified as[a] 2008 Honda Civic, Si 4Dr Sedan, 2.0 L 4 cyl”. Then, computing device412 can “[g]enerat[e] identifier V_SE ‘2008 Honda Civic’ for SE1”,“identifier V_CTE ‘2008 Honda Civic, Si, 4 cyl’ for SE2”, and“identifier V_FTE ‘2008 Honda Civic 2.0 L 4 cyl’ for SE3”. Then, aftergenerating identifiers V_SE, V_CTE, and V_FTE, computing device 412 can“[s]tor[e] V_SE, V_CTE, [and] V_FTE” as also indicted by dialog 910.

In scenario 800, computing device 412 is connected to server S1, and socomputing device 412 determines V_SE, V_CTE, and V_FTE by communicatingVII, such as the obtained VIN, in a query to server S1 and obtainingV_SE, V_CTE, and V_FTE as part of a query response from server S1.

In other scenarios, computing device 412 performs automatic commonvehicle identification without generating part or all of the displayshown as dialog 910. In still other scenarios, computing device 412performs automatic common vehicle identification without generating adisplay shown as dialog 910, but rather generates and/or updates a logfile that includes some or all of the information shown as dialog 910.In still other scenarios, computing device 412 performs automatic commonvehicle identification by generating a display of dialog 910 andgenerating and/or updating a log file.

Scenario 800 a continues from FIG. 8 with technician Tech1 pressing OKbutton 812 without connecting vehicle V1 to computing device 412.Scenario 800 a then proceeds with computing device 412 presenting dialog1010 for “Manual Common Vehicle Identification” as shown in FIG. 10A.

FIG. 10A shows a dialog 1010 related to one technique for manual commonvehicle identification. Dialog 1010 allows a user of computing device412, such as technician Tech1 repairing vehicle V1 of scenario 800 a, toenter a “Year”, “Make”, “Model”, “Style”, “Engine Size”, and a “Numberof cylinders” as VII. In the example shown in FIG. 10, the user hasentered in a year of “2018”, a make of “AAA’, a model of “Model1”, astyle of “Style 1”, an engine size of “2.2 L” (2.2 liters), and a numberof cylinders equal to 4. Dialog 1010 indicates that pull down menus canbe used to provide some or all of the VII—in other examples, more, less,and/or different data can be provided as VII to computing device 412than shown for dialog 1010.

Once the user has entered in the VII data, the user can press button1014 indicating that the VII is “OK” and that computing device 412 canproceed with common vehicle identification. If the user decides to useautomatic common vehicle identification rather than enter the VII viadialog 1012, then the user can press button 1012. Automatic commonvehicle identification is discussed above at least in the context ofFIGS. 5, 6, and 9.

Then, after button 1014 is pressed, computing device 412 can generate aquery based on the VII provided by dialog 1010 for a local databaseresident on computing device 412. In response to the query, computingdevice 412 can receive a query response with one or more vehicleidentifiers for one or more corresponding software executables residenton computing device 412.

FIGS. 10B and 10C show dialogs 1020, 1022, 1030, and 1032 related toanother technique for manual common vehicle identification. In thistechnique, the user provides data about the VIN of vehicle V1 on a VINcharacter-by-character basis until enough VII has been collected toenable computing device 412 to query the local database for vehicleidentifiers for resident software executables as discussed above atleast in the context of FIGS. 4, 5, and 10A.

In particular, an upper portion of FIG. 10B shows dialog 1020 to enterin a “10^(th) VIN Character” which corresponds to the year ofmanufacture for vehicle V1. In the example shown in FIG. 10B, a “C”character is selected corresponding to year “2012”. A lower portion ofFIG. 10B shows dialog 1022 which indicates that the “C” character of aVIN has been selected as the 10^(th) character of the VIN of vehicle V1.Dialog 1022 also includes button 1024 to use automatic common vehicleidentification rather than manual common vehicle identification andbutton 1026 to continue with manual common vehicle identification. Inscenario 800 a, button 1026 is selected to continue with manual commonvehicle identification

After button 1026 is selected, computing device 412 displays dialog1030, an example of which is shown in an upper portion of FIG. 10C.Dialog 1030 can be used to enter in a “4^(th) VIN Character” whichcorresponds to a model of manufacture for vehicle V1. In the exampleshown in FIG. 10B, a “Z” character is selected corresponding to a “Model8” vehicle.

A lower portion of FIG. 10C shows dialog 1032, which indicates that the“Z” character has been selected as a 4^(th) character of the VIN ofvehicle V1. Dialog 1032 shows that “F” has been selected as a 5^(th)character of the VIN of vehicle V1 and that “3” has been selected as a6^(th) character of the VIN of vehicle V1. Dialog 1032 also shows that“C” has been selected as the 10th character of the VIN of vehicle V1 asalso illustrated by dialog 1022. Dialog 1032 indicates that computingdevice 412 has obtained enough data about the VIN to make a suggestionof a “2012 CarCo Model8 Coupe Engine: 2.9 L 16V XXX” as the YMME ofvehicle under repair.

Dialog 1032 includes OK button 1034 that, if selected by a user, allowscomputing device 412 to proceed with common vehicle identification basedon the suggested YMME. Dialog 1032 includes also includes cancel button1036 that, if selected by a user, allows computing device 412 to stopcommon vehicle identification. In other examples, dialog 1032 caninclude additional buttons, such as a “back” or “edit” button to allowchanging of the previously-provided VIN and/or YMME data, and a buttonsuch as button 1024 of dialog 1022 to allow use of automatic commonvehicle identification. In scenario 800 a, technician Tech1 repairingvehicle V1 selects OK button to accept 2012 CarCo Model8 Coupe Engine:2.9 L 16V XXX as the VII (and YMME) for vehicle V1 being repaired, andallowing common vehicle identification to proceed with obtaining vehicleidentifiers for resident software executables based on the VII.

In scenario 800 a, computing device 412 is not connected to a server,and so computing device 412 determines V_SE, V_CTE, and V_FTE byquerying a local database and obtaining V_SE, V_CTE, and V_FTE as partof a query response from the local database. In scenario 800 a, aftervehicle identifiers V_SE, V_CTE, and V_FTE have been obtained, computingdevice 412 is connected to vehicle V1. After vehicle identifiers V_SE,V_CTE, and V_FTE are obtained, scenarios 800 and 800 a both continuewith computing device 412 storing vehicle identifiers V_SE, V_CTE, andV_FTE.

Computing device 412 then displays home page 1100 as shown in FIG. 11.Home page 1100 can act as a vehicle repair home page that can includecontrols for activating various repair-related functions. Theserepair-related functions can be based on resident software executablesof computing device 412.

FIG. 11 shows that home page 1100 includes adaptive PID scanner control1110, adaptive functional testing control 1112, adaptive component testmeter control 1114, technical bulletin control 1116, diagnostic viewcontrol 1130, expert access control 1132, data manager control 1134,vehicle history control 1136, data stream control 1150, help control1152, settings control 1154, and exit control 1156. In other examples,home page 1100 can include more, fewer, and/or different controls thanillustrated.

Adaptive PID scanner control 1110, when selected (i.e., pressed), canactivate the resident adaptive PID scanner executable. The adaptive PIDscanner executable can cause resident software and hardware of computingdevice 412 to communicate vehicle V1 to obtain DTCs, PIDs, parametervalues associated with the PIDs and perhaps other information fromvehicle V1.

Adaptive functional testing control 1112, when selected, can activatethe resident functional test executable for performing tests on aper-function basis on a vehicle; e.g., vehicle V1. Adaptive componenttest meter control 1114, when selected, can activate the residentcomponent test executable for performing tests on a per-component basison a vehicle; e.g., vehicle V1. The resident software executables canuse digital scanners and electronic measuring components, such asdigital oscilloscopes, ammeters, voltmeters, ohmmeters, etc., residenton computing device 412 to perform the respective component andfunctional tests. These component and functional tests can be tailoredon a per-test basis to provide information to technician Tech1 about howto execute the test and/or how to interpret test results.

Technical bulletin control 1116, when selected, can activate a residentsoftware executable for performing vehicle information retrieval. Theexecutable for performing vehicle information retrieval can providerepair tips, OEM repair information, TSBs, and/or other informationrelated to vehicle V1. This executable can present one or more titles orother information about respective items of vehicle information (such asa TSB title about a particular TSB). Subsequent selection of aparticular title causes computing device 412 to send a request for therespective item of vehicle information associated with the title toserver S1. In response, server S1 sends the respective vehicleinformation associated with the title to computing device 412, andcomputing device 412 can display the respective vehicle informationassociated with the title. In some examples, the software executable forperforming vehicle information retrieval can be associated with avehicle identifier; this vehicle identifier can be obtained duringcommon vehicle identification, stored on computing device 412, andprovided to the software executable during activation. In otherexamples, more, fewer, and/or different software executables can beresident on vehicle V1 scan tool and/or accessible via the controls ofthe repair page.

Diagnostic view control 1130, when selected, can cause computing device412 to provide a repair page for diagnosing a vehicle under repair. Thisrepair page can be customized based on a DTC selected by a user ofcomputing device 412; e.g., technician Tech1. If computing device 412 isconnected to a server; e.g., server S1, then the repair page can befurther customized based on enhanced repair data, including intelligentrepair data, provided by the server. The repair page can includecontrols to activate the above-mentioned software executables withinputs including the selected DTC and inputs provided by the server aspart of the enhanced repair data, as well as other controls related torepairing vehicle V1. Examples of this repair page are discussed belowin the context of FIGS. 13A and 14A.

Expert access control 1132, when selected, can cause computing device412 to (attempt to) connect to one or more (off-site) experts for adviceabout using computing device 412 to repair vehicle V1, for advice and/orservice about computing device 412, and/or for other information.Computing device 412 can communicate data, text, audio, video, and/orother information with the connected expert(s); e.g., enablecommunications via telephone, video call, or textual chat, send and/orreceive images and/or data, etc. Data manager control 1134, whenselected, can cause computing device 412 to provide controls forreviewing, updating, inserting, and/or deleting data stored on computingdevice 412; i.e., controls for local data management.

Vehicle history control 1136, when selected, can cause computing device412 to display information about previous repairs and other historicalinformation about a vehicle under repair. Data stream control 1150, whenselected, can cause computing device 412 to display information aboutnetworks and/or devices connected to computing device 412 and providingdata, perhaps as one or more data streams, to computing device 412. Helpcontrol 1152, when selected, can cause computing device 412 to provideadditional information on how to use computing device 412; i.e., help inusing computing device 412.

Settings control 1154, when selected, can cause computing device 412 toprovide a settings page that allows a user of computing device 412 toread, update, insert, and/or delete “settings” or values that controloperation of computing device 412. Example settings include, but are notlimited to, settings related to upgrading and/or installing hardwareand/or software of computing device 412, settings related toalready-installed hardware and/or software of computing device 412(e.g., executable-specific settings) networking-related settings,settings for audio information (e.g., volume), settings for displayinformation (e.g., brightness, color adjustment), settings related tostorage available on and/or used by computing device 412, and settingsrelated to users of computing device 412 (e.g., user names, passwords,user-accessible storage, etc.). Exit control 1156, when selected, cancause computing device 412 to exit home page 1100. In some examples,when exit control 1156 is selected, computing device 412 is powereddown.

For both scenarios 800 and 800 a, technician Tech1 selects adaptive PIDscanner control 1110 to cause computing device 412 to activate theadaptive PID scanner executable. Upon selection of adaptive PID scannercontrol 1110, computing device 412 retrieves vehicle identifier V_SE forthe adaptive PID scanner executable from storage and activates theadaptive PID scanner executable. In scenario 800, vehicle identifiersV_SE, V_CTE, and V_FTE are stored as part of enhanced repair datacommunicated between computing device 412 and the server, and computingdevice 412 retrieves vehicle identifiers from stored enhanced repairdata. In scenario 800 a, vehicle identifiers V_SE, V_CTE, and V_FTE arestored in a vehicle identifier file stored on computing device 412. Bothscenarios 800 and 800 a continue with computing device 412 providing ascanner executable page for the activated adaptive PID scannerexecutable.

FIG. 12 shows scanner executable page 1200 for the adaptive PID scannerexecutable. Scanner executable page 1200 indicates that the adaptive PIDscanner executable first “Scan[s]” vehicle V1 for “DTCs” and receivesthree DTCs from vehicle V1. The three DTCs are: DTC “P0171”, which has atitle of “System Too Lean (Bank1)”, DTC “P0101”, which has a title of“Mass Airflow Sensor ‘A’ Range/Performance”, and DTC “P0121”, which hasa title of “Throttle Position Sensor ‘A’ Circuit Performance”. In someexamples, DTCs and related controls displayed on scanner executable page1200 are presented in order of relative importance for repairing vehicleV1; e.g., repairing faults in vehicle V1 related to DTC P0171 are moreimportant and/or may also repair faults in vehicle V1 related to DTCsP0101 and P0121, and repairing faults in vehicle V1 related to DTC P0101are more important and/or may also repair faults in vehicle V1 relatedto DTC P0121.

Scanner executable page 1200 also includes three controls 1210, 1220,1230. Each of respective controls 1210, 1220, 1230, when selected,indicates to computing device 412 that a user; e.g., technician Tech 1,intends to “repair” one or more faults in vehicle V1 associated withrespective DTCs “P0171”, “P0101”, and “P0121”. In both scenarios 800 and800 a, technician Tech1 selects repair P0171 control 1210 with theintention of repairing one or more faults in vehicle V1 associated withDTC P0171.

To help technician Tech1 repair these faults, computing device 412 canprovide information, tests, displays, and/or other materials related toa DTC associated with a selected control to enable technician Tech1 torepair one or more faults in vehicle V1 related to the DTC. Theinformation, tests, displays, and/or other materials can differ based oninformation provided by server S1; i.e., server S1 can provide computingdevice 412 with enhanced repair information that modifies and/or selectsdifferent information, tests, displays, and/or other materials relatedto a DTC in comparison to default information, tests, displays, and/orother materials resident on computing device 412. Thus, the remainder ofscenario 800 differs from the remainder of scenario 800 a.

Scenario 800 continues with computing device 412 obtaining enhancedrepair information related to DTC P0171 from server S1. Computing device412 subsequently displays repair page 1300 based on the enhanced repairinformation.

FIG. 13A shows that repair page 1300 includes indicator 1302 showingthat the “Server” is “Available”; i.e., server S1 is connected tocomputing device 412. Repair page 1300 also includes controls 1310,1312, 1320, 1322, 1324, 1330, 1332, 1334, 1340, 1342 and suggestedrepair information 1326. Several of these controls; e.g., controls 1310,1312, 1322, 1324, and suggested repair information 1326 are customizedbased on “DTC P0171”, which is the DTC selected from scanner executablepage 1200 using repair P0171 control 1210. Additionally, control 1320 iscustomized based on the enhanced repair data.

P0171 technical bulletin control 1310, when selected, can causecomputing device 412 to provide one or more technical bulletinsassociated with a specific DTC; in this example, DTC P0171. A technicalbulletin can provide information related to diagnosing and/or repairingfaults in vehicle V1, perhaps provided by the OEM of vehicle V1 and/orother repair experts. For example, computing device 412 can obtain thetechnical bulletin(s) associated with DTC P0171 from server S1. In someexamples, P0171 technical bulletin control 1310 can indicate a number oftechnical bulletins available and related to P0171.

Common repairs control 1312 can indicate one or more repair proceduresperformed by other technicians attempting to repair vehicles thatgenerate a specific DTC; in this example, DTC P0171. In this example,the repair procedures are listed in order of a number of attemptsperformed by other technicians; that is, the most commonly attemptedrepair procedure to remedy DTC P0171 is to “Change [the] Fuel Filter”,the second most commonly attempted repair procedure to remedy DTC P0171is to “Replace [the] Oxygen Sensor”, and the third most commonlyattempted repair procedure to remedy DTC P0171 is “Replace Fuel Pump”.Upon selection, common repair control 1312 can provide more informationabout the listed repair procedures; e.g., parts information, relatedmanual pages, images of faulty and/or correct parts, audio and/or videoinformation about performing the repair procedures.

In some examples, common repairs control 1312 indicates one or morerepair procedures performed on vehicles that are similar to or the sameas vehicle V1; e.g., have some or all of the same YMME/VII/vehicleidentifier information as vehicle V1. In other examples, common repairscontrol 1312 provides a graph of common repairs based on a number ofrepair attempts over time; i.e., to indicate if one or more particularrepair procedures have increased or decreased in popularity over time.

Adaptive PID/DTC scanner control 1320, when selected, can causecomputing device 412 to activate the adaptive PID scanner executableand/or redisplay scanner executable page 1200 with the DTCs obtainedfrom vehicle V1. As indicated by the text of control 1320 shown in FIG.13A, adaptive PID/DTC scanner control 1320 can indicate whether or not“Enhanced Repair Data” is “Available”.

Adaptive functional testing control 1322, when selected, can causecomputing device 412 to display a repair page associated with thefunctional test executable and/or activate the functional testexecutable. The enhanced repair data provided by the server can includeone or more identified functional tests that are associated with aspecific DTC; e.g., DTC P0171. Then, when the functional test executableis activated, technician Tech1 can select one or more of the identifiedfunctional tests associated with DTC P0171 for subsequent performance.

Adaptive component testing control 1324, when selected, can causecomputing device 412 to display a repair page associated with thecomponent test executable and/or activate the component test executable.The enhanced repair data provided by the server can include one or moreidentified component tests that are associated with a specific DTC;e.g., DTC P0171. Then, when the component test executable is activated,technician Tech1 can select one or more of the identified componenttests associated with DTC P0171 for subsequent performance.

Suggested repair information 1326 can include one or more tips,procedures, and/or other information suggested by technicians, experts,and/or others to repair one or more faults associated with a specificDTC; e.g., DTC P0171. Suggested repairs control 1330, when selected, cancause computing device 412 to provide additional tips, repairprocedures, and/or other information suggested by technicians, experts,and/or others to repair one or more faults associated with a specificDTC; e.g., DTC P0171. That is, suggested repair information 1326 caninclude repair information that is most commonly read, has a highestuser or other rating, the oldest, the newest, and/or otherwise deemed tobe most important and suggested repairs control 1330 can provide otherrepair information beyond suggested repair information 1326 that is alsoassociated with a specific DTC; e.g., DTC P0171.

Chat with expert control 1332, when selected, can cause computing device412 to initiate communications with one or more persons that haveexpertise related to repairing vehicle faults; e.g., technicians,mechanics, OEM personnel, etc. In some examples, these person(s) canhave expertise related to repairing vehicle faults related to a specificDTC; e.g., DTC P0171. These communications can include data, text,audio, video, and/or other information communicated between computingdevice 412 and the person(s) with expertise.

OEM repair information control 1334, when selected, can cause computingdevice 412 to provide original equipment manufacturer information aboutvehicles that are similar to or the same as vehicle V1; e.g., have someor all of the same YMME/VII/vehicle identifier information as vehicleV1. In some examples, OEM repair information control 1334, whenselected, can cause computing device 412 to provide original equipmentmanufacturer information about similar and/or the same vehicle and alsoabout repairing vehicle faults related to a specific DTC; e.g., DTCP0171.

Control 1340, when selected, can cause computing device 412 to provideany other available controls, information, options, etc. related torepairing a vehicle generating a specific DTC; in this example, DTCP0171. Control 1342, when selected, can cause computing device 412 topower down.

Scenario 800 continues with technician Tech1 selecting adaptivecomponent testing control 1324 to activate the component testexecutable. In response, computing device 412 displays repair page 1350as shown in FIG. 13B.

Repair page 1350 is related to the component test executable. Repairpage 1350 provides a “Component Test View” with component tests and/orresets customized for a specific DTC; e.g., “DTC P0171”. A componenttest can be used to obtain information about a specific component ofvehicle V1, while a component reset can be used to set data for thecomponent to factory-recommended and/or other initial values. Inscenario 800, the customized tests and/or resets are selected bycomputing device 412 from the enhanced repair information provided byserver S1.

More specifically, repair page 1350 includes controls 1352, 1354, 1356,1358 for selection and execution of component tests and/or resets.Respective controls 1352, 1354, 1356, 1358, when selected, can causecomputing device 412 to execute a respective “Fuel Pump”, “OxygenSensor”, “Mass Airflow Sensor”, or “Powertrain Control Module” test onvehicle V1 and report results of the respective fuel pump, oxygensensor, mass airflow sensor, or powertrain control executable test.Based on the results of one or more component tests, technician Tech1can continue to repair vehicle V1 assisted by computing device 412 forexecuting further tests, scanning for additional DTCs/PIDs, replacing,removing, installing, adjusting, and/or otherwise modifying one or morevehicle components, etc.

Control 1360, when selected, can cause computing device 412 to provideadditional component tests and/or resets for selection and executionthan those already displayed on repair page 1350. Repair page 1350 alsoincludes suggested repairs control 1330, chat with expert control 1332,OEM repair information control 1334, and controls 1340 and 1342—each ofthese controls can perform the same (or similar) functions for repairpage 1350 as discussed above in the context of repair page 1300 shown inFIG. 13A.

Scenario 800 continues with technician Tech1 selecting the test fuelpump control 1352 from repair page 1350, which causes computing device412 to activate the component test executable. As part of activating thecomponent test executable, computing device 412 retrieves vehicleidentifier V_CTE from storage and provides vehicle identifier V_CTE tothe component test executable during activation. After activating thecomponent test executable, computing device 412 uses the component testexecutable to execute the fuel pump test and presents results of thefuel pump test. Subsequently, technician Tech1 directs computing device412 to return to repair page 1300 as shown in FIG. 13A. From repair page1300, technician Tech1 selects adaptive functional testing control 1324to activate the functional test executable. In response, computingdevice 412 displays repair page 1370, which is related to the functionaltest executable.

FIG. 13C shows that repair page 1370 provides a “Functional Test View”with functional tests and/or resets customized for a specific DTC; e.g.,“DTC P0171”. A functional test can be used to obtain information about aspecific function of vehicle V1, while a component reset can be used toset data related to the specific function to factory-recommended and/orother initial values. In scenario 800, the customized tests and/orresets are selected by computing device 412 from the enhanced repairinformation provided by server S1.

More specifically, repair page 1370 includes controls 1372, 1374, 1376for selection and execution of the customized functional tests and/orresets. Respective controls 1372, 1374, 1376, when selected, can causecomputing device 412 to execute a respective “Engine Speed ControlFunctional Test”, “Fuel Trim Enable Functional Test”, or “Fuel TrimReset” on vehicle V1 and report results of the respective functionaltest or functional reset. Based on the results of the functional test orreset, technician Tech1 can continue to repair vehicle V1 by executingfurther tests, scanning for additional DTCs/PIDs, replacing, removing,installing, adjusting, and/or otherwise modifying one or more vehiclecomponents, etc.

Control 1378, when selected, can cause computing device 412 to provideadditional functional tests and/or resets for selection and executionthan those already displayed on repair page 1370. Repair page 1370 alsoincludes suggested repairs control 1330, chat with expert control 1332,OEM repair information control 1334, and controls 1340 and 1342—each ofthese controls can perform the same (or similar) functions for repairpage 1370 as discussed above in the context of repair page 1300 shown inFIG. 13A.

Scenario 800 continues with computing device 412 receiving selection ofcontrol 1372 to execute an engine speed functional test, which causescomputing device 412 to activate the functional test executable. As partof activating the functional test executable, computing device 412retrieves vehicle identifier V_FTE from storage and provides vehicleidentifier V_FTE to the functional test executable during activation.After activating the functional test executable, computing device 412uses the functional test executable to execute the engine speedfunctional test and presents results of the engine speed functionaltest.

After the results of the engine speed functional test have beenpresented by computing device 412, technician Tech1 directs computingdevice 412 to request data from vehicle V1 related to six PIDs listed ona PID list. Computing device then displays repair page 1380 for an“Adaptive PID Scanner for DTC P0171” as shown in FIG. 13D.

Repair page 1380 includes a “PID List Adapted for DTC P0171” showing PIDdata 1382 for six parameters: “Engine Speed”, “MAP Sensor”, “Short TermFT Bank 1”. “Short Term FT Bank 2”, “HO2S Bank 1 Sensor 1”, and “ECTSensor” with corresponding respective data of “515 RPM”, “45 kPa”, “−1”,“1”, “0.1”, and “229° F.”. A recommended range of data values and anindication of data being in or out of range for each parameter are alsoprovided on repair page 1380. For example, parameter 1384 a, which isthe “Engine Speed” parameter, has a value of “515 RPM”. The value of 515RPM for parameter 1384 a is indicated on repair page 1380 as being “OK”;that is, the value of 515 RPM for parameter 1384 a is within range 1386a of “500 to 720 RPM”.

As another example, parameter 1384 b, which is the “ECT Sensor”parameter, has a value of “229° F.”. The value of 229° F. for parameter1384 b is indicated on repair page 1380 as being “Not OK”; that is, thevalue of 229° F. for parameter 1384 b is outside of range 1386 b of “190to 221° F.”. Repair page 1380 provides additional graphical indicationsof parameters that are in range or not in range. In particular, FIG. 13Dillustrates repair page 1380 showing in-range parameter values, such asthe value of parameter 1384 a, with black text on a white background andshowing not-of-range parameter values, such as the value of parameter1384 b, with white text on a black background. In other scenarios, moreand/or different graphical indications of parameters that are in rangeand/or not in range are used.

Subsequently, technician Tech1 directs computing device 412 to display arepair view for DTC C0660, which is a DTC that is unrelated to DTC P0171discussed above. Computing device then displays repair page 1300 for“DTC C0660” as shown in FIG. 13E. FIG. 13E indicates that a title forDTC C0660 is “Exhaust Valve Circuit Fault” and uses indicator 1302 tothat the server is “Available” to computing device 412. However, at thisstage of scenario 800, the server determines that no non-defaultinformation is available for DTC C0660 based on the previous scans andtests performed on vehicle V1. Subsequently, display 1390 indicates that“Common Repairs” and “Enhanced Repair Data” is “Unavailable” for thisspecific DTC; e.g., DTC C0660. Also, control 1392 for “Adaptive PID/DTCScanner Control” indicates that “Enhanced Repair Data: is “Unavailable”.Repair page 1300 also includes default controls 1394 and 1396 forrespective “Functional Testing” and a “Component Test Meter”. Repairpage 1300 also includes suggested repairs control 1330, chat with expertcontrol 1332, OEM repair information control 1334, and controls 1340 and1342—each of these controls can perform the same (or similar) functionsfor repair page 1300 as discussed above in the context of FIG. 13A.After repair page 1300 as shown in FIG. 13E is displayed, scenario 800is completed.

Returning to scenario 800 a, after computing device 412 receives theselection for DTC P0171, computing device 412 subsequently displaysrepair page 1400 based on the enhanced repair information.

FIG. 14A shows repair page 1400, which is a default repair page relatedto “DTC P0171”; that is, a repair page related to DTC P0171 that is notbeen modified based on information from the server since computingdevice 412 is not connected to the server. Repair page 1400 includesindicator 1402 showing that the “Server” is “Unavailable”; i.e., serverS1 is not connected to computing device 412. Repair page 1400 alsoincludes displays 1410, 1412 and controls 1414, 1416, 1418, 1422, 1424,1430, and 1432.

Display 1410 indicates that technical bulletins are unavailable; i.e.,since computing device 412 is not connected to server S1. Display 1412instructs technician Tech1 to “connect to server [S1] for common repairsdata”, as a further indication that computing device 412 is notconnected to server S1.

Adaptive PID/DTC scanner control 1414, when selected, can causecomputing device 412 to activate the adaptive PID scanner executableand/or redisplay scanner executable page 1200 with the DTCs obtainedfrom vehicle V1. Adaptive functional testing control 1416, whenselected, can cause computing device 412 to display a repair pageassociated with the functional test executable and/or activate thefunctional test executable. Adaptive component test meter control 1418,when selected, can cause computing device 412 to display a repair pageassociated with the component test executable and/or activate thecomponent test executable.

Chat with expert control 1422, when selected, can cause computing device412 to initiate communications with one or more persons that haveexpertise related to repairing vehicle faults, as described above in thecontext of chat with expert control 1332. OEM repair information control1424, when selected, can cause computing device 412 to provide originalequipment manufacturer information about vehicles that are similar to orthe same as vehicle V1, as described above in the context of OEM repairinformation control 1334.

Control 1430, when selected, can cause computing device 412 to provideany other available controls, information, options, etc. related torepairing a vehicle generating a specific DTC; in this example, DTCP0171. Control 1432, when selected, can cause computing device 412 topower down.

Scenario 800 a continues with technician Tech1 selecting adaptivecomponent test meter control 1418 to activate the component testexecutable. In response, computing device 412 displays repair page 1450as shown in FIG. 14B.

Repair page 1450 is related to the component test executable and is adefault page presented when a “Server” is “Unavailable” as indicated byindicator 1402. Repair page 1450 provides access to a default set ofcomponent tests and/or resets that may be related to specific DTC; e.g.,“DTC P0171”.

More specifically, repair page 1450 includes controls 1452, 1454, 1456,1458 for selection and execution of component tests and/or resets.Respective controls 1452, 1454, 1456, 1458, when selected, can causecomputing device 412 to execute a respective “Fuel Pressure Regulator”,“Fuel Pump”, “Powertrain Control Module”, or “Oxygen Sensor” test onvehicle V1 and report results of the respective fuel pressure regulator,fuel pump, powertrain control executable, or oxygen sensor test. Basedon the results of one or more component tests, technician Tech1 cancontinue to repair vehicle V1 assisted by computing device 412 forexecuting further tests, scanning for additional DTCs/PIDs, replacing,removing, installing, adjusting, and/or otherwise modifying one or morevehicle components, etc. Note that the default set of tests and/orresets available via controls 1452, 1454, 1456, 1458 of repair page 1450differs from the customized set of tests and/or resets available viacontrols 1352, 1354, 1356, 1358 of repair page 1350; that is, thecustomization performed by server S1 for scenario 800 changes thedefault set of component tests for scenario 800 a.

FIG. 14B indicates that control 1460, when selected, can cause computingdevice 412 to provide additional component tests and/or resets forselection and execution than those already displayed on repair page1450. Repair page 1450 also includes chat with expert control 1422, OEMrepair information control 1424, and controls 1430 and 1432—each ofthese controls can perform the same (or similar) functions for repairpage 1450 as discussed above in the context of repair page 1400 shown inFIG. 14A.

Scenario 800 a continues with technician Tech1 selecting the test fuelpressure regulator control 1452 from repair page 1450, which causescomputing device 412 to activate the component test executable. As partof activating the component test executable, computing device 412retrieves vehicle identifier V_CTE from storage and provides vehicleidentifier V_CTE to the component test executable during activation.After activating the component test executable, computing device 412uses the component test executable to execute the fuel pressureregulator and presents results of the fuel pressure regulator test.Subsequently, technician Tech1 directs computing device 412 to return torepair page 1400 as shown in FIG. 14A. From repair page 1400, technicianTech1 selects adaptive functional testing control 1416 to activate thefunctional test executable. In response, computing device 412 displaysrepair page 1470, which is related to the functional test executable.

FIG. 14C shows that repair page 1470 provides a “Functional Test View”and is a default page presented when a “Server” is “Unavailable” asindicated by indicator 1402 Repair page 1470 provides access to adefault set of functional tests and/or resets that may be related tospecific DTC; e.g., “DTC P0171”.

More specifically, repair page 1470 includes controls 1472, 1474 forselection and execution of the default set of functional tests and/orresets. Respective controls 1372, 1374, when selected, can causecomputing device 412 to execute a respective “Fuel Trim Reset” or “FuelTrim Enable Functional Test” on vehicle V1 and report results of therespective functional test or reset. Based on the results of thefunctional test or reset, technician Tech1 can continue to repairvehicle V1 by executing further tests, scanning for additionalDTCs/PIDs, replacing, removing, installing, adjusting, and/or otherwisemodifying one or more vehicle components, etc. Note that the default setof tests and/or resets available via controls 1472, 1474 of repair page1470 differs from the customized set of tests and/or resets availablevia controls 1372, 1374, 1376 of repair page 1350; that is, thecustomization of functional tests performed by server S1 for scenario800 changes the default set of functional tests used in scenario 800 a.

FIG. 14C indicates that control 1476, when selected, can cause computingdevice 412 to provide additional functional tests and/or resets forselection and execution than those already displayed on repair page1470. Repair page 1470 also includes chat with expert control 1422, OEMrepair information control 1424, and controls 1430 and 1432—each ofthese controls can perform the same (or similar) functions for repairpage 1470 as discussed above in the context of repair page 1400 shown inFIG. 14A.

Scenario 800 a continues with computing device 412 receiving selectionof control 1472 to execute a fuel trim enable reset, which causescomputing device 412 to activate the functional test executable. As partof activating the functional test executable, computing device 412retrieves vehicle identifier V_FTE from storage and provides vehicleidentifier V_FTE to the functional test executable during activation.After activating the functional test executable, computing device 412uses the functional test executable to execute the fuel trim enablereset and presents results related to the fuel trim enable reset.

After the results of the fuel trim enable reset have been presented bycomputing device 412, technician Tech1 directs computing device 412 torequest data from vehicle V1 related to six PIDs listed on a PID list.Computing device then displays repair page 1480 for a “Default PID Listfor DTC P0171” as shown in FIG. 14D. In scenarios 800 and 800 a, theadapted PID list provided by server S1 in scenario 800 and illustratedby repair page 1380 of FIG. 13D is the same PID list as the default PIDlist of scenario 800 a illustrated by repair page 1480 of FIG. 14D. Inother scenarios, adapted PID lists provided by server S1 may, but neednot, differ from default PID lists.

Repair page 1480 shows PID data 1482 for six parameters: “Engine Speed”,“MAP Sensor”, “Short Term FT Bank 1”. “Short Term FT Bank 2”, “HO2S Bank1 Sensor 1”, and “ECT Sensor” with corresponding respective data of “515RPM”, “45 kPa”, “−1”, “1”, “0.1”, and “229”. A recommended range of datavalues and an indication of data being in or out of range for eachparameter are also provided on repair page 1480. For example, parameter1484 a, which is the “Engine Speed” parameter, has a value of “515 RPM”.The value of 515 RPM for parameter 1484 a is indicated on repair page1480 as being “OK”; that is, the value of 515 RPM for parameter 1484 ais within range 1486 a of “500 to 720 RPM”.

As another example, parameter 1484 b, which is the “ECT Sensor”parameter, has a value of “229° F.”. The value of 229° F. for parameter1484 b is indicated on repair page 1480 as being “Not OK”; that is, thevalue of 229° F. for parameter 1484 b is outside of range 1486 b of “190to 221° F.”. Repair page 1480 provides additional graphical indicationsof parameters that are in range or not in range. In particular, FIG. 14Dillustrates repair page 1480 showing in-range parameter values, such asthe value of parameter 1484 a, with black text on a white background andshowing not-of-range parameter values, such as the value of parameter1484 b, with white text on a black background. In other scenarios, moreand/or different graphical indications of parameters that are in rangeand/or not in range are used. After displaying repair page 1480,scenario 800 a can be completed.

Example Computing Network

FIG. 15 is a block diagram of example computing network 1500 inaccordance with an example embodiment. In FIG. 15, servers 3414, 1508,and 1510 are configured to communicate, via a network 1506, withcomputing device 412 at repair facility 1520 and perhaps with technician416, as well as with client devices 1504 a, 1504 b, and 1504 c. As shownin FIG. 15, client devices can include a personal computer 1504 a, alaptop computer 1504 b, and a smart-phone 1504 c. More generally, clientdevices 1504 a-1504 c (or any additional client devices) can be any sortof computing device, such as a workstation, network terminal, desktopcomputer, laptop computer, wireless communication device (e.g., a cellphone or smart phone), and so on. Server 414 is discussed above in thecontext of at least FIGS. 4-13E. Computing device 412 at repair facility1520 is also discussed above in the context of at least FIGS. 4-14D. Inthe context of computing network 1500, computing device 412 can act as aclient device.

Network 1506 can correspond to a local area network, a wide areanetwork, a corporate intranet, the public Internet, combinationsthereof, or any other type of network(s) configured to providecommunication between networked computing devices. In some embodiments,part or all of the communication between networked computing devices canbe secured.

Servers 414, 1508, and 1510 can share content and/or provide content atleast to computing device 412 and client devices 1504 a-1504 c, wherethe content can include images, video, audio, computer-readable data,and/or other types of available information directly or indirectlyaccessible via servers 414, 1508, and 1510. As shown in FIG. 15, servers414, 1508, and 1510 are not physically at the same location.Alternatively, some or all servers 414, 1508, and 1510 can beco-located, and/or can be accessible via one or more networks separatefrom network 1506. Although FIG. 15 shows four client devices (includingcomputing device 412) and three servers, network 1506 can service moreor fewer than four client devices and/or more or fewer than threeservers.

Example Computing Device

FIG. 16A is a block diagram of an example computing device 1600, inaccordance with an embodiment. In particular, computing device 1600 canbe configured to perform one or more functions of and/or related toherein-described VII, herein-described vehicle identifiers, aherein-described vehicle scan tool, a herein-described server,herein-described enhanced repair data, a herein-described softwareexecutable, vehicle identifier file 310, enhanced repair data 330,vehicle 410, computing device 412, server 414, server S1, vehicle V1,client devices 1504 a-1504 c, network 1506, and/or servers 1508, 1510and/or at least a portion of one or more of: method 200, communicationflow 400, communication flow 500, communication flow 600, communicationflow 700, scenario 800, scenario 800 a, and/or method 1700.

Computing device 1600 can be a desktop computer, laptop or notebookcomputer, personal data assistant (PDA), mobile phone, embeddedprocessor, touch-enabled device, or any similar device that is equippedwith at least one processing unit capable of executing machine-languageinstructions that implement at least a portion of the herein-describedtechniques and methods, including, but not limited to, method 200,communication flow 400, communication flow 500, communication flow 600,communication flow 700, scenario 800, scenario 800 a, and/or method1700.

Computing device 1600 may include a user interface executable 1601, anetwork communication interface executable 1602, one or more processors1603, and data storage 1604, all of which may be linked together via asystem bus, network, or other connection mechanism 1605. User interfacemodule 1601 can receive input and/or provide output, perhaps to a user.

User interface module 1601 can be configured to send and/or receive datato and/or from user input from input device(s), such as a keyboard, akeypad, a touch screen, a computer mouse, a track ball, a joystick,and/or other similar devices configured to receive input from a user ofthe computing device 1600.

User interface module 1601 can be configured to generate and/or providevisible output via one or more output display devices, such as cathoderay tubes (CRTs), liquid crystal displays (LCDs), plasma devices, lightemitting diodes (LEDs), displays using digital light processing (DLP)technology, printers, light bulbs, monitors, touch screens, and/or othersimilar devices capable of displaying graphical, textual, and/ornumerical information to a user of computing device 1600. User interfacemodule 1601 can also be configured to generate and/or provide audibleoutput(s) via one or more audio output devices, such as speakers,speaker jacks, audio output ports, earphones, and/or other similardevices configured to convey sound and/or audible information to a userof computing device 1600. User interface module 1601 can further beconfigured to generate and/or provide haptic output(s) via one or morehaptic output devices, such as vibration devices and/or other devicesconfigured to convey touch-related and/or haptic information to a userof computing device 1600.

Network communication interface module 1602 can be configured to sendand receive data over wireless interface 1607 and/or wired interface1608 via a network, such as network 1506. Wireless interface 1607 ifpresent, can utilize an air interface, such as a Bluetooth®, Wi-Fi®,ZigBee®, and/or WiMAX™ interface to a data network, such as a wide areanetwork (WAN), a local area network (LAN), one or more public datanetworks (e.g., the Internet), one or more private data networks, or anycombination of public and private data networks. Wired interface(s)1608, if present, can comprise a wire, cable, fiber-optic link and/orsimilar physical connection(s) to a data network, such as a WAN, LAN,one or more public data networks, one or more private data networks, orany combination of such networks. Network communication interface module1602 can be configured to communicate with one or more vehicles, such asvehicle 410, using one or more communications interfaces; e.g., anOBD-II protocol interface, a Bluetooth® interface, a Wi-Fi® interface, aZigBee® interface.

In some embodiments, network communication interface module 1602 can beconfigured to provide reliable, secured, and/or authenticatedcommunications. For each communication described herein, information forensuring reliable communications (i.e., guaranteed message delivery) canbe provided, perhaps as part of a message header and/or footer (e.g.,packet/message sequencing information, encapsulation header(s) and/orfooter(s), size/time information, and transmission verificationinformation such as CRC and/or parity check values). Communications canbe made secure (e.g., be encoded or encrypted) and/or decrypted/decodedusing one or more cryptographic protocols and/or algorithms, such as,but not limited to, DES, AES, RSA, Diffie-Hellman, and/or DSA. Othercryptographic protocols and/or algorithms can be used as well as or inaddition to those listed herein to secure (and then decrypt/decode)communications. In some cases, such communications can also, or instead,be compressed communications; in these cases, network communicationinterface module 1602 can be configured to compress uncompressedcommunications and/or decompress compressed communications.

Processor(s) 1603 can include one or more central processing units,computer processors, mobile processors, digital signal processors(DSPs), graphics processing units (GPUs), microprocessors, computerchips, and/or other processing units configured to executemachine-language instructions and process data. Processor(s) 1603 can beconfigured to execute computer-readable program instructions 1606 thatare contained in data storage 1604 and/or other instructions asdescribed herein.

Data storage 1604 can include one or more physical and/or non-transitorystorage devices, such as read-only memory (ROM), random access memory(RAM), removable-disk-drive memory, hard-disk memory, magnetic-tapememory, flash memory, and/or other storage devices. Data storage 1604can include one or more physical and/or non-transitory storage deviceswith at least enough combined storage capacity to containcomputer-readable program instructions 1606 and any associated/relateddata and data structures.

In embodiments of the disclosure in which a computer software product isused, the product may be non-transitory and store instructions on one ormore physical media and/or devices, such as a DVD, a solid state drive,a hard drive, or any other non-transitory computer-readable media orstorage devices disclosed herein. Alternatively, the product may betransitory and in the form of instructions provided over a connectionsuch as a network connection which is linked to a network such as theInternet.

Computer-readable program instructions 1606 and any data structurescontained in data storage 1604 include computer-readable programinstructions executable by processor(s) 1603 and any storage required,respectively, to perform at least part of herein-described of theherein-described techniques and methods, including, but not limited to,method 200, communication flow 400, communication flow 500,communication flow 600, communication flow 700, scenario 800, scenario800 a, and/or method 1700.

Testing/scanning components 1620 can include components for scanning,testing, and/or repairing a vehicle. These components can include, butare not limited to, one or more OBD-II (i.e., DTC/PID) scanners,electronic measuring components, test leads, data ports, power supplies,digital oscilloscopes, digital ammeters, digital voltmeters, digitalohmmeters, and digital multi-meters. In some embodiments, some or all ofthe herein described software executables can be included astesting/scanning components 1620. In other embodiments, testing/scanningcomponents 1620 and/or data storage 1604 can store VII and/or one ormore vehicle identifiers, perhaps by storing one or more vehicleidentifier files and/or one or more instances of enhanced repair data.

FIG. 16B depicts a network 1506 of computing centers 1609 a, 1609 b,1609 c in accordance with an example embodiment. Data and/or softwarefor server 414 and/or server S1 can be stored on one or more cloud-baseddevices that store program logic and/or data of cloud-based applicationsand/or services. In some embodiments, server 414 and/or server S1 can bea single computing device residing in a single computing center. Inother embodiments, server 414 and/or server S1 can include multiplecomputing devices in a single computing center, or even multiplecomputing devices located in multiple computing centers located indiverse geographic locations.

In some embodiments, data and/or software for server 414 and/or serverS1 can be encoded as computer readable information stored in computerreadable media and/or non-transitory computer readable storage media andaccessible by client devices 1504 a, 1504 b, and 1504 c, and/or othercomputing devices (e.g., computing device 412). In some embodiments,data and/or software for server 414 and/or server S1 can be stored on asingle disk drive or other non-transitory and/or tangible storage media,or can be implemented on multiple disk drives or other non-transitoryand/or tangible storage media located at one or more diverse geographiclocations.

FIG. 16B depicts a cloud-based server system in accordance with anexample embodiment. In FIG. 16B, the functions of server 414 and/orserver S1 can be distributed among three computing centers 1609 a, 1609b, and 1608 c. Computing center 1609 a can include one or more computingdevices 1600 a, storage devices 1610 a, and communication devices 1611 a(e.g., router(s), hub(s), switch(es)) connected by local network 1612 a.Similarly, computing center 1609 b can include one or more computingdevices 1600 b, storage devices 1610 b, and communication devices 1611 bconnected by local network 1612 b. Likewise, computing center 1609 c caninclude one or more computing devices 1600 c, storage devices 1610 c,and communication devices 1611 c connected by local network 1612 c.

In some embodiments, each of computing centers 1609 a, 1609 b, and 1609c can have equal numbers of computing, storage, and communicationdevices. In other embodiments, however, each computing center can havedifferent numbers of computing, storage, and/or communication devices.The number of computing, storage, and communication devices in eachcomputing center can depend on the computing task or tasks assigned toeach computing center.

In computing center 1609 a, for example, computing devices 1600 a can beconfigured to perform various computing tasks of server 414 and/orserver S1. In one embodiment, the various functionalities of server 414and/or server S1 can be distributed among one or more of computingdevices 1600 a, 1600 b, and 1600 c. Computing devices 1600 b and 1600 cin computing centers 1609 b and 1609 c can be configured similarly tocomputing devices 1600 a in computing center 1609 a. On the other hand,in some embodiments, computing devices 1600 a, 1600 b, and 1600 c can beconfigured to perform different functions.

In some embodiments, computing tasks and stored data associated withserver 414 and/or server S1 can be distributed across computing devices1600 a, 1600 b, and 1600 c based at least in part on the processingrequirements of server 414 and/or server S1, the processing capabilitiesof computing devices 1600 a, 1600 b, and 1600 c, the latency of thenetwork links between the computing devices in each computing center andbetween the computing centers themselves, and/or other factors that cancontribute to the cost, speed, fault-tolerance, resiliency, efficiency,and/or other design goals of the overall system architecture.

The storage devices 1610 a, 1610 b, and 1610 c of computing centers 1609a, 1609 b, and 1609 c can be data storage arrays that include disk arraycontrollers configured to manage read and write access to groups of harddisk drives. The disk array controllers, alone or in conjunction withtheir respective computing devices, can also be configured to managebackup or redundant copies of the data stored in the storage devices toprotect against disk drive or other storage device failures and/ornetwork failures that prevent one or more computing devices fromaccessing one or more storage devices.

Similar to the manner in which the functions of server 414 and/or serverS1 can be distributed across computing devices 1600 a, 1600 b, and 1600c of computing centers 1609 a, 1609 b, and 1609 c, various activeportions and/or backup portions of these components can be distributedacross storage devices 1610 a, 1610 b, and 1610 c. For example, somestorage devices can be configured to store one portion of the dataand/or software of server 414 and/or server S1, while other storagedevices can store other, separate portions of the data and/or softwareof server 414 and/or server S1. Additionally, some storage devices canbe configured to store backup versions of data and/or software stored inother storage devices.

Communication devices 1611 a, 1611 b, and 1611 c can include networkingequipment configured to provide internal and external communications forcomputing centers 1609 a, 1609 b, 1609 c. For example, communicationdevices 1611 a in computing center 1609 a can include one or moreinternet switching and routing devices configured to provide (i) localarea network communications between computing devices 1600 a and storagedevices 1610 a via local network 1612 a, and (ii) wide area networkcommunications between computing center 1609 a and the computingfacilities 1609 b and 1609 c via connection 1613 a to network 1506.Communication devices 1611 b and 1611 c can include network equipmentsimilar to communication devices 1611 a, and communication devices 1611b and 1611 c can perform similar networking functions for computingcenters 1609 b and 1609 b that communication devices 1611 a perform forcomputing center 1609 a.

In some embodiments, the configuration of communication devices 1611 a,1611 b, and 1611 c can be based at least in part on the communicationrequirements of the computing devices and storage devices, thecommunications capabilities of network equipment in the communicationdevices 1611 a, 1611 b, and 1611 c, the latency and throughput of localnetworks 1612 a, 1612 b, 1612 c, the latency, throughput, and cost ofconnections 1613 a, 1613 b, and 1613 c, and/or other factors that cancontribute to the cost, speed, throughput, fault-tolerance, resiliency,efficiency and/or other design goals for computing centers 1609 a, 1609b, 1609 c.

Example Methods of Operation

FIG. 17 is a flow chart of method 1700, in accordance with anembodiment. Method 1700 can be carried out by a computing device, suchas computing device 1600 discussed above in the context of FIG. 16. Insome embodiments, the computing device can act and/or be embodied as avehicle scan tool while carrying out part or all of method 1700.

Method 1700 can begin at block 1710, where the computing device candetermine VII that identifies a vehicle and where the computing deviceincludes a first software executable and a second software executable,such as discussed above at least in the context of FIGS. 2-14D.

In some embodiments, the computing device can be connected to thevehicle; then, determining the VII can include: sending a request forthe VII from the computing device to the vehicle; and receiving the VIIat the computing device from the vehicle, such as discussed above atleast in the context of FIGS. 2, 3, 6, and 7.

In other embodiments, the VII can include a VIN for the vehicle, such asdiscussed above at least in the context of FIGS. 2-10C.

In still other embodiments, the first software executable can beconfigured for one or more functions of: a vehicle scanning function, avehicle testing function, and a repair-information retrieval function,such as discussed above at least in the context of FIGS. 2-14D.

At block 1720, the computing device can store, a first vehicleidentifier associated with the first software executable and a secondvehicle identifier associated with the second software executable, whereboth the first and second vehicle identifiers are based on the VII, andwhere the first vehicle identifier differs from the second vehicleidentifier, such as discussed above at least in the context of FIGS.2-10C.

In some embodiments, the computing device can be communicatively coupledto a server computing device; then, storing the first vehicle identifierassociated with the first software executable and the second vehicleidentifier associated with the second software executable can include:providing a first query to the server computing device, the first querybased on an identifier of the first software executable and the VII;after providing the first query to the server computing device,receiving a first query response to the first query from the servercomputing device; determining the first vehicle identifier based on thefirst query response; and storing the first vehicle identifier at thecomputing device, such as discussed above at least in the context ofFIGS. 2, 3, 6, and 7.

In other embodiments, the computing device can include an identifierdatabase and the computing devices is not communicatively coupled to aserver computing device for determining vehicle identifiers; then,storing the first vehicle identifier associated with the first softwareexecutable and the second vehicle identifier associated with the secondsoftware executable can include: providing a first query to theidentifier database, the first query based on the identifier of thefirst software executable and the VII; after providing the first queryto the identifier database, receiving a first query response to thefirst query from the identifier database; determining the first vehicleidentifier based on the first query response; and storing the firstvehicle identifier, such as discussed above at least in the context ofFIGS. 2-5.

In still other embodiments, storing the first vehicle identifierassociated with the first software executable and the second vehicleidentifier associated with the second software executable based on theVII can include: providing a first query based on the VII; receiving afirst query response to the first query; determining the first vehicleidentifier and the second vehicle identifier based on the first queryresponse; and storing the first vehicle identifier and the secondvehicle identifier at the computing device, such as discussed above atleast in the context of FIGS. 2-4, 6, and 8-10C.

In even other embodiments, storing the first vehicle identifierassociated with the first software executable and the second vehicleidentifier associated with the second software executable based on theVII can include: providing a first query based on the VII and anidentifier of the first software executable; after providing the firstquery, receiving a first query response to the first query; determiningthe first vehicle identifier based on the first query response; storingthe first vehicle identifier at the computing device; providing a secondquery based on the VII and an identifier of the second softwareexecutable, where the second query differs from the first query; afterproviding the second query, receiving a second query response to thesecond query; determining the second vehicle identifier based on thesecond query response; and storing the second vehicle identifier at thecomputing device, such as discussed above at least in the context ofFIGS. 5 and 7.

At block 1730, the computing device can be used in repairing the vehicleby at least: receiving a request to activate the first softwareexecutable, and activating the first software executable at least byproviding the stored first vehicle identifier to the first softwareexecutable, such as discussed above at least in the context of FIGS. 2,4-7, and 12-14D.

In some embodiments, repairing the vehicle further includes: receiving arequest to activate the second software executable; and activating thesecond software executable at least by providing the stored secondvehicle identifier to the second software executable, such as discussedabove at least in the context of FIGS. 2, 4-7, and 12-14C.

In other embodiments, the computing device can further include a homepage with a plurality of activation controls for activating a pluralityof software executables; then, activating the first software executablecan include activating the first software executable using an activationcontrol for activating the first software executable of the home page,such as discussed above in the context of at least FIGS. 11-14D.

In still other embodiments, the computing device can be connected to thevehicle; then, repairing the vehicle can include: after activating thefirst software executable, sending a request for repair-relatedinformation to the vehicle; receiving the repair-related informationfrom the vehicle; and generating a display of the computing device basedon the repair-related information, such as discussed above in thecontext of at least FIGS. 4-7 and 11-14D. In particular of theseembodiments, the repair-related information can include data associatedwith one or more PIDs and/or one or more DTCs, such as discussed abovein the context of FIGS. 11-14D. In more particular of these embodiments,the repair-related information can include a particular DTC; then,generating the display based on the repair-related information includes:determining information about one or more tests and/or repairs relatedto the particular DTC; and generating a display based on the informationabout one or more tests and/or repairs related to the particular DTC),such as discussed above in the context of FIGS. 12-14D. In even moreparticular of these embodiments, determining the information about oneor more tests and/or repairs related to the particular DTC can include:sending a query including the particular DTC to a server computingdevice; and receiving, from the server computing device, the informationabout one or more tests and/or repairs related to the particular DTC,such as discussed above in the context of FIGS. 12-13E. In other evenmore particular of these embodiments, determining the information aboutone or more tests and/or repairs related to the particular DTC caninclude: determining the information about one or more tests and/orrepairs related to the particular DTC utilizing data stored on thecomputing device, such as discussed above in the context of FIGS. 12 and14A-14D.

Unless the context clearly requires otherwise, throughout thedescription and the claims, the words ‘comprise’, ‘comprising’, and thelike are to be construed in an inclusive sense as opposed to anexclusive or exhaustive sense; that is to say, in the sense of“including, but not limited to”. Words using the singular or pluralnumber also include the plural or singular number, respectively.Additionally, the words “herein,” “above” and “below” and words ofsimilar import, when used in this application, shall refer to thisapplication as a whole and not to any particular portions of thisapplication.

The above description provides specific details for a thoroughunderstanding of, and enabling description for, embodiments of thedisclosure. However, one skilled in the art will understand that thedisclosure may be practiced without these details. In other instances,well-known structures and functions have not been shown or described indetail to avoid unnecessarily obscuring the description of theembodiments of the disclosure. The description of embodiments of thedisclosure is not intended to be exhaustive or to limit the disclosureto the precise form disclosed. While specific embodiments of, andexamples for, the disclosure are described herein for illustrativepurposes, various equivalent modifications are possible within the scopeof the disclosure, as those skilled in the relevant art will recognize.

All of the references cited herein are incorporated by reference.Aspects of the disclosure can be modified, if necessary, to employ thesystems, functions and concepts of the above references and applicationto provide yet further embodiments of the disclosure. These and otherchanges can be made to the disclosure in light of the detaileddescription.

Specific elements of any of the foregoing embodiments can be combined orsubstituted for elements in other embodiments. Furthermore, whileadvantages associated with certain embodiments of the disclosure havebeen described in the context of these embodiments, other embodimentsmay also exhibit such advantages, and not all embodiments neednecessarily exhibit such advantages to fall within the scope of thedisclosure.

The above detailed description describes various features and functionsof the disclosed systems, devices, and methods with reference to theaccompanying figures. In the figures, similar symbols typically identifysimilar components, unless context dictates otherwise. The illustrativeembodiments described in the detailed description, figures, and claimsare not meant to be limiting. Other embodiments can be utilized, andother changes can be made, without departing from the spirit or scope ofthe subject matter presented herein. It will be readily understood thatthe aspects of the present disclosure, as generally described herein,and illustrated in the figures, can be arranged, substituted, combined,separated, and designed in a wide variety of different configurations,all of which are explicitly contemplated herein.

With respect to any or all of the ladder diagrams, scenarios, and flowcharts in the figures and as discussed herein, each block and/orcommunication may represent a processing of information and/or atransmission of information in accordance with example embodiments.Alternative embodiments are included within the scope of these exampleembodiments. In these alternative embodiments, for example, functionsdescribed as blocks, transmissions, communications, requests, responses,and/or messages may be executed out of order from that shown ordiscussed, including substantially concurrent or in reverse order,depending on the functionality involved. Further, more or fewer blocksand/or functions may be used with any of the ladder diagrams, scenarios,and flow charts discussed herein, and these ladder diagrams, scenarios,and flow charts may be combined with one another, in part or in whole.

A block that represents a processing of information may correspond tocircuitry that can be configured to perform the specific logicalfunctions of a herein-described method or technique. Alternatively oradditionally, a block that represents a processing of information maycorrespond to a module, a segment, or a portion of program code(including related data). The program code may include one or moreinstructions executable by a processor for implementing specific logicalfunctions or actions in the method or technique. The program code and/orrelated data may be stored on any type of computer readable medium suchas a storage device including a disk or hard drive or other storagemedium.

The computer readable medium may also include non-transitory computerreadable media such as computer-readable media that stores data forshort periods of time; e.g., volatile memory, register memory, processorcache, and/or random access memory (RAM). The computer readable mediamay also include non-transitory computer readable media that storesprogram code and/or data for longer periods of time; e.g., non-volatilememory, secondary or persistent long term storage, read only memory(ROM), optical or magnetic disks, compact-disc read only memory(CD-ROM). The computer readable media may also be any other volatile ornon-volatile storage systems. A computer readable medium may beconsidered a computer readable storage medium, for example, or atangible and/or non-transitory storage medium and/or device.

Moreover, a block that represents one or more information transmissionsmay correspond to information transmissions between software and/orhardware modules and/or executables in the same physical device.However, other information transmissions may be between software and/orhardware modules and/or executables in different physical devices.

Numerous modifications and variations of the present disclosure arepossible in light of the above teachings.

Embodiments of the present disclosure may relate to one or more of theenumerated example embodiments (EEEs) listed below.

EEE 1 is a method comprising: determining, at a computing device,vehicle identification information (VII) that identifies a vehicle,wherein the computing device comprises a first software executable and asecond software executable; storing, at the computing device, a firstvehicle identifier associated with the first software executable and asecond vehicle identifier associated with the second software executablebased on the VII, wherein the first vehicle identifier differs from thesecond vehicle identifier; and repairing the vehicle using the computingdevice by at least: receiving a request to activate the first softwareexecutable, and activating the first software executable at least byproviding the stored first vehicle identifier to the first softwareexecutable.

EEE 2 is the method of EEE 1, wherein repairing the vehicle furthercomprises: receiving a request to activate the second softwareexecutable; and activating the second software executable at least byproviding the stored second vehicle identifier to the second softwareexecutable.

EEE 3 is the method of EEE 1 or EEE 2, wherein the computing device iscommunicatively coupled to a server computing device, and whereinstoring the first vehicle identifier associated with the first softwareexecutable and the second vehicle identifier associated with the secondsoftware executable comprises: providing a first query to the servercomputing device, the first query based on an identifier of the firstsoftware executable and the VII; after providing the first query to theserver computing device, receiving a first query response to the firstquery from the server computing device; determining the first vehicleidentifier based on the first query response; and storing the firstvehicle identifier at the computing device.

EEE 4 is the method of any one of EEEs 1-3, wherein the computing devicecomprises an identifier database and is not communicatively coupled to aserver computing device for determining vehicle identifiers, and whereinstoring the first vehicle identifier associated with the first softwareexecutable and the second vehicle identifier associated with the secondsoftware executable comprises: providing a first query to the identifierdatabase, the first query based on the identifier of the first softwareexecutable and the VII; after providing the first query to theidentifier database, receiving a first query response to the first queryfrom the identifier database; determining the first vehicle identifierbased on the first query response; and storing the first vehicleidentifier.

EEE 5 is the method of any one of EEEs 1-4, wherein storing the firstvehicle identifier associated with the first software executable and thesecond vehicle identifier associated with the second software executablebased on the VII comprises: providing a first query based on the VII;receiving a first query response to the first query; determining thefirst vehicle identifier and the second vehicle identifier based on thefirst query response; and storing the first vehicle identifier and thesecond vehicle identifier at the computing device.

EEE 6 is the method of any one of EEEs 1-5, wherein storing the firstvehicle identifier associated with the first software executable and thesecond vehicle identifier associated with the second software executablebased on the VII comprises: providing a first query based on the VII andan identifier of the first software executable; after providing thefirst query, receiving a first query response to the first query;determining the first vehicle identifier based on the first queryresponse; storing the first vehicle identifier at the computing device;providing a second query based on the VII and an identifier of thesecond software executable, wherein the second query differs from thefirst query; after providing the second query, receiving a second queryresponse to the second query; determining the second vehicle identifierbased on the second query response; and storing the second vehicleidentifier at the computing device.

EEE 7 is the method of any one of EEEs 1-6, wherein the computing deviceis connected to the vehicle, and wherein determining the VII comprises:sending a request for the VII from the computing device to the vehicle;and receiving the VII at the computing device from the vehicle.

EEE 8 is the method of any one of EEEs 1-7, wherein the VII comprises avehicle identification number (VIN) for the vehicle.

EEE 9 is the method of any one of EEEs 1-8, wherein the first softwareexecutable is configured for one or more functions of: a vehiclescanning function, a vehicle testing function, and a repair-informationretrieval function.

EEE 10 is the method of any one of EEEs 1-9, wherein the computingdevice further comprises a home page with a plurality of activationcontrols for activating a plurality of software executables, and whereinactivating the first software executable comprises activating the firstsoftware executable using an activation control for activating the firstsoftware executable of the home page.

EEE 11 is the method of any one of EEEs 1-10, wherein the computingdevice is connected to the vehicle, and wherein repairing the vehiclecomprises: after activating the first software executable, sending arequest for repair-related information to the vehicle; receiving therepair-related information from the vehicle; and generating a display ofthe computing device based on the repair-related information.

EEE 12 is the method of EEE 11, wherein the repair-related informationcomprises data associated with one or more parameter identifiers (PIDs)and/or one or more diagnostic trouble codes (DTCs).

EEE 13 is the method of EEE 12, wherein the repair-related informationcomprises a particular DTC, and wherein generating the display based onthe repair-related information comprises: determining information aboutone or more tests and/or repairs related to the particular DTC; andgenerating a display based on the information about one or more testsand/or repairs related to the particular DTC.

EEE 14 is the method of EEE 13, wherein determining the informationabout one or more tests and/or repairs related to the particular DTCcomprises: sending a query including the particular DTC to a servercomputing device; and receiving, from the server computing device, theinformation about one or more tests and/or repairs related to theparticular DTC.

EEE 15 is the method of either EEE 13 or EEE 14, wherein determining theinformation about one or more tests and/or repairs related to theparticular DTC comprises determining the information about one or moretests and/or repairs related to the particular DTC utilizing data storedon the computing device.

EEE 16 is a computing device, comprising: a processor; and a computerreadable medium configured to store at least a first softwareexecutable, a second software executable, and executable instructions,wherein the executable instructions, when executed by the processor,cause the computing device to perform functions comprising the method ofany one of EEE 1 to EEE 15.

EEE 17 is a non-transitory computer readable medium configured to storeat least executable instructions, wherein the executable instructions,when executed by a processor of a computing device, cause the computingdevice to perform functions comprising the method of any one of EEE 1 toEEE 15.

The invention claimed is:
 1. A method, comprising: determining vehicleidentification information (VII) that identifies a vehicle to beserviced; determining repair-related information about the vehicle by:receiving a request to activate a first software executable at a firstserver; after receiving the request to activate the first softwareexecutable, activating the first software executable at least by:transmitting a query to a second server other than the first server,wherein the query is based on the first software executable at the firstserver and includes a first vehicle identifier based on the VII;receiving a second vehicle identifier from the second server in responseto the query, wherein the second vehicle identifier is associated withboth the vehicle to be serviced and the first software executable at thefirst server; and providing the received second vehicle identifier tothe first server as part of initiating execution of the first softwareexecutable; determining the repair-related information about the vehiclebased on execution of the first software executable; and generating adisplay based on the repair-related information about the vehicle.
 2. Amethod according to claim 1, further comprising: retrieving, from alocal database based on the VII, the first vehicle identifier based onthe VII.
 3. A method according to claim 2, wherein the VII includes atleast some of a vehicle identification number (VIN) of the vehicle, andwherein the first vehicle identifier based on the VII is indicative oneor more from among: a vehicle year, a vehicle make, a vehicle model, anengine type, or a fuel type.
 4. A method according to claim 1, whereinthe first server is stored on a first cloud-based server and the secondserver is stored on a second cloud-based server other than the firstcloud-based server.
 5. A method according to claim 1, whereindetermining the VII that identifies the vehicle to be serviced comprisesdetermining the VII that identifies the vehicle to be serviced using acomputing device.
 6. A method according to claim 5, wherein thecomputing device is connected to the vehicle, and wherein determiningthe VII comprises: sending a request for the VII from the computingdevice to the vehicle; and receiving the VII at the computing devicefrom the vehicle.
 7. A method according to claim 5, wherein thecomputing device is connected to the vehicle, and wherein the methodfurther comprises: after activating the first software executable,sending a request for second repair-related information to the vehicle;receiving the second repair-related information from the vehicle; andgenerating a second display of the computing device based on the secondrepair-related information.
 8. A method according to claim 1, whereinthe first software executable is configured for a repair-informationretrieval function.
 9. A method according to claim 1, wherein activatingthe first software executable comprises activating the first softwareexecutable using an activation control of a page for activating thefirst software executable, the page comprising a plurality of activationcontrols for activating a plurality of software executables.
 10. Amethod according to claim 1, wherein the repair-related informationcomprises data associated with one or more parameter identifiers (PIDs)and/or one or more diagnostic trouble codes (DTCs).
 11. A methodaccording to claim 10, wherein the repair-related information comprisesa particular DTC, and wherein generating the display based on therepair-related information about the vehicle comprises: determininginformation about one or more tests and/or repairs related to theparticular DTC; and generating a display based on the information aboutone or more tests and/or repairs related to the particular DTC using acomputing device.
 12. A method according to claim 11, whereindetermining the information about one or more tests and/or repairsrelated to the particular DTC comprises: sending a query including theparticular DTC to a server computing device; and receiving, from theserver computing device, the information about one or more tests and/orrepairs related to the particular DTC.
 13. A method according to claim11, wherein determining the information about one or more tests and/orrepairs related to the particular DTC includes using data stored on thecomputing device.
 14. A method according to claim 1, wherein the queryincludes only a portion of the VII.
 15. A method according to claim 1,wherein the query includes an entirety of the VII.
 16. A methodaccording to claim 1, further comprising: displaying a home pageincluding a first activation control, wherein receiving the request toactivate the first software executable at the first server includesusing the first activation control.
 17. A method according claim 1,wherein the received second vehicle identifier comprises a suggestedvehicle identifier based on the first vehicle identifier; the methodfurther comprising: receiving a selection to proceed with using thesuggested vehicle identifier based on the first vehicle identifier. 18.A method according to claim 17, further comprising: displaying, on adisplay, one or more VII entry pages, wherein determining VII thatidentifies the vehicle to be serviced includes determining VII based onselections made via the one or more VII entry pages.
 19. A methodaccording to claim 1, further comprising: receiving one or more othervehicle identifiers different than the second vehicle identifier inresponse to the query.
 20. A method according to claim 1, wherein thesecond vehicle identifier includes one or more vehicle attributes thanindicated by the first vehicle identifier.
 21. A computing device,comprising: a processor; and a computer readable medium configured tostore at least executable instructions that, when executed by theprocessor, cause the computing device to perform functions comprising:determining vehicle identification information (VII) that identifies avehicle to be serviced; determining repair-related information about thevehicle by: receiving a request to activate a first software executableat a first server; after receiving the request to activate the firstsoftware executable, activating the first software executable at leastby: transmitting a query to a second server other than the first server,wherein the query is based on the first software executable at the firstserver and includes a first vehicle identifier based on the VII;receiving a second vehicle identifier from the second server in responseto the query, wherein the second vehicle identifier is associated withboth the vehicle to be serviced and the first software executable at thefirst server; and providing the received second vehicle identifier tothe first server as part of initiating execution of the first softwareexecutable; determining the repair-related information about the vehiclebased on execution of the first software executable; and generating adisplay based on the repair-related information about the vehicle.
 22. Anon-transitory computer readable medium configured to store at leastexecutable instructions, wherein the executable instructions, whenexecuted by a processor of a computing device, cause the computingdevice to perform functions comprising: determining vehicleidentification information (VII) that identifies a vehicle to beserviced; determining repair-related information about the vehicle by:receiving a request to activate a first software executable at a firstserver; after receiving the request to activate the first softwareexecutable, activating the first software executable at least by:transmitting a query to a second server other than the first server,wherein the query is based on the first software executable at the firstserver and includes a first vehicle identifier based on the VII;receiving a second vehicle identifier from the second server in responseto the query, wherein the second vehicle identifier is associated withboth the vehicle to be serviced and the first software executable at thefirst server; and providing the received second vehicle identifier tothe first server as part of initiating execution of the first softwareexecutable; determining the repair-related information about the vehiclebased on execution of the first software executable; and generating adisplay based on the repair-related information about the vehicle.